Drupal High

update_sql is not my friend

krs — Wed, 07 Jan 2009 22:51:53 -0800

Oh update_sql(), second most unloved of the drupal database functions (db_rewrite_sql() is worse)! If you've never used it, it is basically a wrapper for db_query() that you can use in hook_update_N() hooks in a module .install file. You may never need to write one of these hooks unless you maintain a module; or like me you prefer to make database changes via code when I'm pushing some new features out to dev, stage, and live servers.

The Drupal 6 and 7 versions of the documentation for this function do mention that "%-substitution parameters are not supported." Definitely also true for the Drupal 5 version I'm still working with. So you can't do variable substitution like you do with db_query() and most of the time thats not a big deal.

There is one very important time though.

When using db_query(), you call it with a syntax like db_query($sql, $variable1, $variable2); Now, you know about database prefixes, and always sing curly braces around your table names in FROMs and JOINs, and that lets Drupal work on multisite installs very well, or talk to more than one DB at a time. So the $sql part of that function call always gets passed through a strtr(), or in English, PHP's string translate function that converts every instace of '{' to the right prefix (generally just deletes it). You have no choice about this, and no way to prevent it from getting every single { and }!

So far so good, because you only use curly braces around the table names, and that works out just fine, right?

Now enter update_sql(). This function doesn't support variable substitution, so your function calls look are just update_sql($sql).

Like update_sql("UPDATE {node} SET title = 'something else' WHERE nid = 10"); - that is, everything has to be passed as part of a single SQL statement (the $sql part above). The SQL statement that always gets run through strtr() looking for '{' and '}'. Which, if you are trying to update a serialized array, or a block's visibility code with PHP, or just want to use a { in a node title, it will be deleted. Every time, without exception.

So if you're using update_sql() and any part of the data contains a '{' or '}' that you need to keep intact - rewrite it as a db_query() with variable substitution. The strtr() will operate on the $sql part, and the $values get substituted in later and stay intact.

How to hook_views_tables_alter()

krs — Wed, 07 Jan 2009 00:50:21 -0800

First of all, this only applies to Views1 & Drupal 5 - there's probably a similar function in views2 however.

The setup: A timestamp ($node->created) was being selected in a View. The only options for formatting it are as Short, Long, Medium, Time Ago, or Custom. With custom you can enter any string that can be interpreted by php's date() function, and have that format apply.

The problem: The site that used a different format as its standard for displaying date and time, let's say "D F j, Y \a\t g:i A". We had created a function in template.php called site_format_date() that accepted a timestamp, and returned the date nicely formatted that way. All for reuseability! Now all the dates in the code (and template files, and theme function overrides) we write can call that function. And when Mrs. Editor decides that she really would like it to be something completely different, we can change it in one place and be done!

The table problem: What a pain to have to go to each View that uses a time or date, and select the "custom" format, and enter into the textbox the format we want to use. Now when someone wants to change the site-wide format, we'll have to go back to each view and update all the format fields! Argh!

So what we're trying to do, is somehow add our own custom format as one of the options for displaying a timestamp, in addition to the basic ones Drupal and Views provides us. Unfortunately, those choices are created by a call to views_handler_field_dates(), which just returns a fixed array of those 5 choices, and there's no way to get your own in there.

hook_views_tables_alter() to the rescue! This hook lets you modify how the Views module understands the tables in the Drupal database. Most of the core tables are added by .inc files in the views module, and many contrib modules have their own views.inc file. Using this hook you have the opportunity to change anything you like about how views works with modules, and do it safely without hacking any modules.

The fields I wanted to affect (the created and changed timestamp) are node fields. You can see them defined in path/to/views/modules/views_node.inc. I'm trying affect how the fields are handled (as opposed to filters, arguments, sorts, or anything else). By checking the .inc file I can see the keys I want to affect are simply called 'created' and 'changed'. Putting that all together, here is my complete hook function :

function hook_views_tables_alter(&$tabledata) {
$tabledata['node']['fields']['created']['handler']['my_custom_format_date'] = t('As My Custom Date');
$tabledata['node']['fields']['changed']['handler']['my_custom_format_date'] = t('As My Custom Date');
}

Now when I can choose "As My Custom Date" to format the timestamps! Views will automatically call my_custom_format_date() for me, and I just pass the data right along to our sitewide date formatter.

function my_custom_format_date($fieldinfo, $fielddata, $value, $data) {
return $value ? site_format_date($value) : theme('views_nodate');
}

If figuring out the syntax of the array to modify was a little confusing (views syntax? confusing? never!) try this little snippet first:

function hook_views_tables_alter(&$tabledata) {
drupal_set_message(print_r($tabledata, TRUE));
}

and you'll get a very long printout of how every table interacts with the Views module. With some searching and little luck, you should be able to find the section you want to modify. Lots of great views1 and views2 documentation is available, but it gets a little hairy! Unfortunately there's not a lot of documentation that I could find on this very powerful hook! I discovered it while poking through the views.module code and found 1 Drupal issue at http://drupal.org/node/142383. (This was the issue that actually enabled the hook to work properly as of about July 2007).

Remind me to add some pictures to this post!

Imagecache and You (err, your picture)

krs — Tue, 06 Jan 2009 23:21:42 -0800

When you using imagecache on the $user->picture, many people have noticed 1 small problem. If someone uploads a new picture, everything appears to work fine, but the user photo stays the same!

What's going on? When a user uploads a picture, it gets renamed to a specific filename - doesn't matter the name of the file you uploaded. Imagecache then makes a copy of that file to display. (Technically this doesn't happen until the first time the image is viewed with a particular preset). When the new user image is uploaded, it gets the very same name as the previous one, again regardless of the actual filename that was uploaded. Now imagecache will think it already has a cached version of that image, because it just checks the filename and sees that it exists!

So I was all about to post on how to fix that, basically by linking to Nate Haug's excellent post on how to do just that - but the Imagecache module maintainers have just made a new release (for Drupal 5) that includes a fix for the issue! So the new solution is - download the latest version of the Imagecache module!

Ampersands and CCK

krs — Tue, 06 Jan 2009 22:58:15 -0800

When using a CCK text field that is set to display as a select list, using the "Allowed Values" textarea to specify each of the choices works 99% of the time. But when trying to use an option that included an ampersand, like "Drupal & Drupal", it keeps getting escaped to & - stop it CCK!

What's going on? Each line of the textarea is eventually passed through filter_xss(), which tries it's best to remove naughty characters like &, becauseof its special meaning in HTML.

How to avoid it? Use the section "PHP Code" and write your values out as an array. You must specify a key and value pair for each option, CCK will not automatically handle just having the value. Don't forget to return the array. PHP open and closing tags arent needed. CCK trusts the values found in this block, and pass them through any kind of text filtering, and your ampsersands will sail through undamaged.

Drupal & Drupal
Hans & Franz
Martin & Lewis

become

return array(
'Drupal & Drupal' => 'Drupal & Drupal',
'Hans & Franz' => 'Hans & Franz',
'Martin & Lewis' => 'Martin & Lewis',
);