Recent comments

  • Calendar with highlighted dates   1 year 17 weeks ago

    Calendar module + Date module + Views does very similar thing in Drupal 7 (there is a views block for month view).

  • Using Ubercart to sell files: ui improvements and creating file feature programmatically   1 year 19 weeks ago

    This would be awesome as a module. The current Ubercart file-selling functionality is pretty atrocious - it makes things have to happen from within two separate interfaces, and is utterly useless except for a one-seller-one-site paradigm. I'm working on a site where the idea is that multiple people would be able to upload and sell their own e-books.

    Even if you don't create a module (which there is seriously a need for!) the above code should be enough to let a developer hack together their own implementation.

    Thanks so much! I thought I was going to have to go through the Ubercart code line-by-line, in the absence of friendly documentation.

  • Manage your Drupal website faster: best modules available   1 year 20 weeks ago

    This module can be useful for simple post-moderation approach - as all the functionality works.

  • Calendar with highlighted dates   1 year 20 weeks ago

    Any Idea if there is a Module that Allows this now? I've been searching everywhere for something like this.

  • Sending emails with attachments in Ubercart   1 year 24 weeks ago

    This article was written for Drupal 6.x - and in Drupal 7.x, CA was replaced by Rules module.

  • Sending emails with attachments in Ubercart   1 year 26 weeks ago

    Am unable to find the CA module in drupal?

    Please help me.

    Thanks in advance

  • It's time for updates   1 year 27 weeks ago

    Our theme demo website now uses simulcasting for code, but divide database. And I think we are going to switch to single file later.

  • Be careful with Views Custom Field   1 year 31 weeks ago

    Hello anton,

    Great tips, thanks, I also always found this view bad behaviour :), but we can avoid this by not using the same custom field for different content types, try to use unique field for every content types, not just avoiding this view bad behaviour :), it will also speed up drupal auto query from view, you can feel it when you deal with a big data

  • Adding "Price" field to Ubercart cart page   1 year 32 weeks ago

    Try this, which avoids errors.

    function hook_tapir_table_alter(&$table, $table_id) {
    if ($table_id != 'uc_cart_view_table') return;
    // Register new column to tapir

    $table['#columns']['price_item'] = array(
    'cell' => t('Price'),
    'weight' => 2.5, );
    foreach (element_children($table) as $key) {
    if (empty($table[$key]['nid']['#value'])) continue;
    // This db-expensive node_load call can be easily avoided by using
    // single SQL select. But,
    // that's not so important if visitor usually adds 1-5 products to cart.
    $n = node_load($table[$key]['nid']['#value']);
    $p = $n->sell_price; // Add data to our new column
    $table[$key]['price_item'] = array(
    '#theme' => 'uc_price',
    '#price' => $p,
    '#cell_attributes' => array('class' =>array('price')) );
    }
    }

  • Using Ubercart to sell files: ui improvements and creating file feature programmatically   1 year 36 weeks ago

    Helo Anton Sidashin

    Of course this code would very useful for many people by creating a module.

    Maybe it can be also integrated with feeds_import module.

  • Image title as text description for colorbox image formatter (Drupal 7)   1 year 36 weeks ago

    Just wanted to say THANKS!

    Jaya

  • Rules won't work properly when run during cron, if you use node access restrictions   1 year 39 weeks ago

    But running as uid=1 isn't the right solution; it would be better if you could choose the scheduled task to run as:
    a) uid=0 (anonymous)
    b) uid=1
    c) the uid of the user who triggered the task.

    To do so rules should save the uid of the user who triggered the task (I don't know if it already does), and the scheduled task should run between this function calls:

    function mymodule_su($uid = 1) {
    global $user;
    if (!array_key_exists('mymodule_su', $_SESSION)) {
    $_SESSION['mymodule_su'] = array();
    }
    array_push($_SESSION['mymodule_su'], $user);
    session_save_session();
    $user = user_load($uid);
    }

    function mymodule_unsu() {
    global $user;
    if (array_key_exists('mymodule_su', $_SESSION)) {
    if (!empty($_SESSION['mymodule_su'])) {
    $user = array_pop($_SESSION['mymodule_su']);
    }
    if (empty($_SESSION['mymodule_su'])) {
    unset($_SESSION['mymodule_su']);
    }
    }
    }

  • Disabling module updates   1 year 43 weeks ago

    It is working fine in D7. Try to clear all caches after .info update.

  • Disabling module updates   1 year 43 weeks ago

    This seems to no longer work in Drupal 7... I've changed the project and I can still get update data for the module. Any idea?

  • Storing monetary amounts in db? Use decimals, not floats!   1 year 44 weeks ago

    Thanks. Tell me if updated example looks better now :)

  • Storing monetary amounts in db? Use decimals, not floats!   1 year 44 weeks ago

    Ryan :)
    let’s pretend you’re a Drupal user with no programming skills.
    How can you use integers in fields in your entity? You need to

    1. Prepare field formatter (since I don’t see any D7 modules for that - correct me if I’m wrong)
    2. If you have some programming skills, but you build something on top of another balance or ubercart module, you need to convert integers to floats back and forth when you deal with these modules. Every time something goes from external module to your module.

    That’s what I was trying to say.

  • Storing monetary amounts in db? Use decimals, not floats!   1 year 44 weeks ago

    bojanz's post is great, and I'd follow-up your point about fields with cross-database server compatibility. MySQL has decimals, but does every other system Drupal users use? If not, your field module would not be usable for them, right?

  • Storing monetary amounts in db? Use decimals, not floats!   1 year 44 weeks ago

    Oh, I forgot about the conversion to pounds for display. We used a modifier in a smarty template:

    {$price_pence|pence_as_pounds)

    Or for our multi-currency sites:

    {$price_pence|pence_as_pounds:$currency_code)

    This would add the decimal place in the correct location and add the currency symbol. We even made it locale-aware, so an Irish site would might show €12.34 where the same site in Spain would show 12,34€

  • Storing monetary amounts in db? Use decimals, not floats!   1 year 44 weeks ago

    Another vote for integers, but I'd also point out (as some people above have hinted at) that you should keep the currency as an integer throughout your application.

    This is the big benefit of integers over MySQL decimals - you can be confident that as your value gets passed between database, PHP, XML service, web framework or whatever that there are no rounding errors being introduced.

    As part of our migration strategy from using floats we also made it super-clear what we were doing by ensuring we added a _pence suffix to all our variables (you might prefer _cents). It wouldn't be a surprise to see a line like this in our code:

    $price_pence = intval(($_GET['price'] * 100) + 0.5);

    There are a couple of things worth noting here - first is the use of intval() rather than round(). That is because round() will return a float! We add 0.5 to emulate the "round to closest" behaviour of round().

    Second, we've got price_pence on the left, and price with a multiplier on the right. I'm changing the data, so I'm changing the identifier. If I saw

    $price_pence = $foo['price']

    then I would immediately check that it was doing the correct thing and if it was then add a comment for the confusing variable names.

  • Storing monetary amounts in db? Use decimals, not floats!   1 year 44 weeks ago

    I agree that storing integers can be a good solution.
    But when we talk about fields, I find it way easier to use decimals.

  • Storing monetary amounts in db? Use decimals, not floats!   1 year 44 weeks ago

    Yes, its definitely easier using integers to store and do the math on, then format the currency/value on the display side. Drupal Commerce does this. It is -way- easier than dealing with floats/decimals.

  • Storing monetary amounts in db? Use decimals, not floats!   1 year 44 weeks ago

    Exactly, your best bet is storing the amount as an integer in one column, and the precision in the other column.
    This is what GnuCash does as well.

    MySQL might allow you to use decimals, but PHP has no such concept by default, so as soon as you get your amount from the db, it's once again prone to rounding errors.
    This is why PHP has BCMath and GMP and we are in fact evaluating using phpseclib.sourceforge.net/math/intro.html for Commerce 2.x (wraps both libraries, and provides a userspace fallback if both are missing).

  • Storing monetary amounts in db? Use decimals, not floats!   1 year 44 weeks ago

    What Garett Albright describes here is exactly the way the Money CCK Field dealt with it, and I suspect Drupal Commerce does too :)

  • Storing monetary amounts in db? Use decimals, not floats!   1 year 44 weeks ago

    +1 for using integers as much as possible. Just have "1" equal one of the lowest unit in the given currency (one cent, one yen, one pre-decimalization British pence) and do the math from there. Or even have "1" equal one hundredth of a cent, if necessary. Then all the problems of dealing with decimal numbers exist only when you need to do the multiplication to display the amount in a human-readable amount (for example, multiply the number of cents by 100 to get the dollar amount).

  • Storing monetary amounts in db? Use decimals, not floats!   1 year 44 weeks ago

    My Money CCK field module for Drupal 5 also used integers: http://drupalcode.org/project/money.git/blob/refs/heads/5.x-1.x:/money.m....

Drupal association member