An italic pipe

Take a very good look at following 2 characters:  / (*1) and /. If you are familiar with a keyboard and a bit of html, you'll find out soon that the first is a pipe ( | ) between <em> tags, which is used on the web to display things in italic. The second is just a plain simple forward slash. Where am I going you think ? Well, I heard a story today from a colleague who once got a question from a friend asking how he could make the pipe sign on his keyboard italic so he could finally enter a website in the address bar of his browser. After all those stressing hours today and yesterday, this was the icebreaker for me and other people at work. We have a blackboard on our wall where we simply added this: http:<em>||</em> People who don't understand it, don't worry. Those who do: it was so funny this afternoon when we heard about this, I guess it's probably stupid when you're reading it. Nevertheless, I think this would suit in the 'horrible questions for a helpdesk' sphere. Oh yeah, and we also launched Expo 58 today. *1 If you are reading this on oerwoud, this doesn't have the effect I'm aiming at, you should look at the original post


humor, work

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

Garfield minus garfield

Everybody knows the cat Garfield from the comic, they even made (horrible) movies about him. But what happens if we leave garfield out of the comic ? Quote from the site: the result is an even better comic about schizophrenia, bipolar disorder, and the empty desperation of modern life. Especially this one is hilarious:



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 which will hopefully serve as a patch for D7.


drupal, hooks

Goodbye sweet passwords

I just installed my own openid identity server on my own URL so I can finally login on other websites with my own openID. Now I don't have to worry about passwords anymore and I'm going to be very strict about this: any new site not supporting openID will be gladly ignored by me from now on. And the ones I like allready might get a friendly mail from me :)




Subscribe to RSS