things you might have overlooked

I just pulled my hair out looking for what caused this, but eventually found it after scanning the module files. The issue was that overriding hook_theme_blocks wasn't possible in some theme. The version in the theme wouldn't get called at all, even after rebuilding the theme registry by clearing the cache. The culprit was the Block Translation module.

I've bumped my head over this one a few times now and I always tend to forget. If you're implementing hook_boot, the module cache (system table) needs to be rebuilt. You can do this by going to admin/build/module.

Why is this? hook_boot is called during the bootstrap like this:

/**
 * Call all init or exit hooks without including all modules.
 *
 * @param $hook
 *   The name of the bootstrap hook we wish to invoke.
 */
function bootstrap_invoke_all($hook) {
  foreach (module_list(TRUE, TRUE) as $module) {
    drupal_load('module', $module);
    module_invoke($module, $hook);
  }
}

As you can see, module_list is called here with the second parameter set to TRUE. Looking at what this parameter means, gives us $bootstrap. Let's look at the (partial) implementation of the module_list function to see what it's used for:

function module_list($refresh = FALSE, $bootstrap = TRUE, $sort = FALSE, $fixed_list = NULL) {
//...
      if ($bootstrap) {
        $result = db_query("SELECT name, filename, throttle FROM {system} WHERE type = 'module' AND status = 1 AND bootstrap = 1 ORDER BY weight ASC, filename ASC");
      }
//...      
}

We're filtering on bootstrap = 1 when selecting from the system table.

As you know or not know, this table only gets (re)built when the available modules are scanned. This happens when module_rebuild_cache is run. This is what gets done if you go to your modules page.

We were struggling with performance issues on a client's site for some time now. We pinned down the real cause today. It was hidden very well as a bug in the Advanced User module.

I'm writing this down here since I'll probably make the same mistake myself sooner or later:

"Usage of t() in a global context, such as define(‘CONST’, t(‘...’)). The locale system is not yet initialized at that time, so this usage is incorrect and also leads to nasty performance problems. Never do it."

I got this quote from Gábor Hojtsy's Drupal 6 Translation Cheat Sheet.

The date Drupal shows on search results is not the date the node was created. Instead it is the date the node was indexed by the search indexer.
Most of the time this is the wanted behavior. Your nodes get indexed when cron is run and if you run cron each 5 or 15 minutes this date is within 15 minutes of the creation date.

But the date is far off when import your nodes from another system. Sometimes this date has been created years ago, and then the time between creation and indexing is long.

As always there's an easy fix for this in Drupal. The search results are themed via theme_search_item and we all know how to override a theme function.

We just have to change

  if ($item['date']) {
    $info[] = format_date($item['date'], 'small');
  }

to

  if(isset($item['node'])) {
  	$info[] = format_date($item['node']->created, 'small');
  } elseif ($item['date']) {
    $info[] = format_date($item['date'], 'small');
  }

So we get:

function phptemplate_search_item($item, $type) {
  $output = ' <h3><a href="'. check_url($item['link']) .'">'. check_plain($item['title']) .'</a></h3>';
  $info = array();
  if ($item['type']) {
    $info[] = check_plain($item['type']);
  }
  if ($item['user']) {
    $info[] = $item['user'];
  }
  /*if ($item['date']) {
    $info[] = format_date($item['date'], 'small');
  }*/
  if(isset($item['node'])) {
  	$info[] = format_date($item['node']->created, 'small');
  } elseif ($item['date']) {
    $info[] = format_date($item['date'], 'small');
  }
  if (is_array($item['extra'])) {
    $info = array_merge($info, $item['extra']);
  }
  $output .= ' <div>'. ($item['snippet'] ? '<p>'. $item['snippet'] .'</p>' : '') .'<p class="search-info">'. implode(' - ', $info) .'</p></div>';
  return $output;
}

Quick note to people who have page caching on on their site:

If you move your site to a new url, don't forget to flush your cache_page table after moving the site since Drupal uses the full url (including the domain name etc.) as the cache key.