node_load after switching database + cck = dangerous

While everyone agrees the node_load() function and the CCK and Content module are two fantastic things, be carefull using node_load when switching your database in code. The current database you're on doesn't necessarily know which modules are activated on the other database/site and what the properties are of the node you're trying to retrieve. This all makes sense to me now, but I had to learn this the hard way spending 8 hours debugging an enormous and enoying problem where data sometimes was completely corrupted coming back.

CCK uses its own cache table to store data to gain more performance. That's fine. Let's imagine we are on site A, create our node with many properties (hence, lot's of extra cck widgets) and save this to the database. We can look at it, edit etc, it will work just fine. Now, let's switch to our second site where we have a tiny little function which simply does this:

$node = node_load(1);
db_set_active('default'); // or siteB

Everyone with a bit of Drupal knowledge will know we'll get a full node object back from the database. But there's a lot happening in the background: node_load, module_invoke_all('hook_load') invoking content_load in CCK and here's where things went wrong this afternoon. CCK has it's own hook system calling other cck widgets to know their properties and fields we associated with our node. When there's nothing cached, CCK builds it's own cached object with all existing fields etc, but when you call this from site B and say the 'filefield.module' isn't enabled, cck will not see this, thus leaving out any uploaded properties in the node object we want to retrieve (CCK will also miss other settings, but I don't want to elaborate on this to much). Yet, we have defined this filefield in site A before. What happens now in site A is simple: we view or edit our node, but we are now retrieving the cached cck object and we see missing properties ('see' is very ironic, but you get the point right?). Frustration is wat's left if you encounter this the first time.

Oh well, luckily the French fries were very good :)


drupal, cck, planet

Extend node filters form

I've been wanting to extend the default node_filter_form on admin/content/node since ages so I finally wrote my own patch because I really needed it for some projects. The patches attached introduce a new hook called hook_node_filters. Modules can hook into the default node_filters function to add their own select boxes and types to filter on. An example hook could look like this:

* Implementation of hook_node_filters().
* Returns extra filter option at admin/content/node to filter on every page.
function testmodule_node_filters() {
$q = "SELECT n.nid, n.title FROM {node} n WHERE n.type = 'page'";
$result = db_query(db_rewrite_sql($q));
   while (
$row = db_fetch_object($result)) {
$options[$row->nid] = $row->title;
   return array(
'page' => array(
'title' => 'page',
'options' => $options,
'where' => 'n.nid = %d',
'join' => '')

Although I'm pretty sure this patch is safe, this is not an official patch reviewed by the Drupal community. In the event something might go wrong, don't hold me responsible allright ? ;) Also, take a look at http://drupal.org/project/better_node_admin_content which will hopefully serve as a patch for D7.


drupal, hooks


I did an upgrade of my site to Drupal 6 this evening and so far everything looks fine. If you encounter problems, let me know! Not depending on cck & views is a major advantage even after D6 is out for almost two months now. In fact, I only have the spam module to replace - or find another solution - because there is no 6 version out yet for it. For now you always must preview your comment, I wonder (probably naively) if spambots can circumvent this ;-)

I've tested D6 a few times allready at work, but not on a production site yet. The drag & drop features and the actions/triggers module are really wonderfull and I'm sure I'll discover some more cool features in the days to come.

update 2/4 : I just installed mollom on my site, so you can now submit comments directly!



Imagecrop on drupal cvs

I just added my imagecrop module to cvs on Drupal. A 5.x development version should be out soon, so everyone is invited to test and submit patches. A lot of things need to be optimized, especially the javascript and css. If anyone is interested being a co-maintainer, I'd be glad to give access to cvs also.

This module makes a javascript toolbox action available thanks to the power of Imagecache 2. It can currently 'hook' into the image module and cck imagefield widget. It provides a 'javascript crop' link on the edit form of an image node or a node with an imagefield widget. The popup window displays all available imagecache presets with a javascript crop action. In your theming you can use the imagecache theme function with a preset and the imagecache action makes a database call to choose the right crop area you have chosen.

More info, CVS and downloads on http://drupal.org/project/imagecrop and a screencast is also available.


drupal, imagecrop

Imagecache 2 and imagecrop

I made a small screencast about a new Drupal module I'm currently writing. It uses imagecache 2 and it's ability to let other modules define their own actions. My module provides a javascript crop action and a cropping box on the image you want to crop. It currently can hook into the imagefield widget and knows which presets in imagecache are available with the 'javascript crop' action. The difference with eyedrop and imagefield_crop is that it doesn't provide its own image cropping widget, instead we hook into the existing imagefield. It is not fully finished yet, but you can see a preview underneath.

Things I would like to see happening in the future:

  • Hook into more modules (image, gallery etc).
  • Get this patch into ImageCache 2. (the patch isn't needed anymore!)
  • Merge this module with eyedrop & imagefield crop / combine our efforts since Imagecache has a really strong API.


Subscribe to RSS - drupal

You are here