module development

One of the smaller improvements in Drupal 7 is the addition of "Configure" and "Permissions" for each module in the modules configuration page. For each module we now have quicklinks pointing to the module's configuration page and the correct section on the "permissions" page.

Since we're all working hard now on making our contributed modules Drupal 7 compatible, I wanted to mention here how to make use of this small feature in your own module.
The "permissions" link is added there automatically by Drupal. For the "Configure" link you need to add one more line to your module's info file.

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.

Sometimes you want to pass a url as a path argument. Drupal explodes urls by slash (/) to get the separate "arguments". Since the passed url probably also contains slashes, this will give erroneous results.

Using the following functions (compress_string and decompress_string) you can safely pass urls now and read them well at the other end.

Example:

print url('bookmark/add/'. compress_string('some/path/on/my/site?query=test'));

function compress_string($string) {
  return urlsafe_base64_encode(gzcompress($string, 9));
}

function decompress_string($string) {
  return gzuncompress(urlsafe_base64_decode($string));
}

function urlsafe_base64_encode($string) {
    $data = base64_encode($string);
    $data = str_replace(array('+','/','='),array('-','_',''),$data);
    return $data;
}

function urlsafe_base64_decode($string) {
    $data = str_replace(array('-','_'),array('+','/'),$string);
    $mod4 = strlen($data) % 4;
    if ($mod4) {
        $data .= substr('====', $mod4);
    }
    return base64_decode($data);
}

We all know our Drupal sites can gain a huge performance boost by enabling page caching. But sometimes, you want to exclude certain pages from being cached.

One option to do such a thing is using a small module called CacheExclude.

You might also opt to program this yourself in your own modules by setting the cache variable to FALSE. Variables can be set temporarily for the current request by setting the global array conf.

A small example might clarify things. We're disabling caching on the front page here (not a thing you'd like to do every day, but it's an example ;)).

if (drupal_is_front_page()) {
  $GLOBALS['conf']['cache'] = FALSE;
}

This is just a quick caveat (or reminder). If you delete a variable from the variables table, always clear the cached entry of the variables too. Drupal caches the whole variables table in the cache table in an entry called 'variables'.

Here are two cases (of the many) you'll need this.

When you're writing your own module and you're setting some variables, always clean them up. Fastest way is by issuing a direct query to the database.

/**
 * Implementation of hook_uninstall().
 */
function my_module_uninstall() {
  db_query("DELETE FROM {variable} WHERE name LIKE 'my_module_%'");
  cache_clear_all('variables', 'cache');
}

A second typical case I can come up with is when releasing the cron semaphore after it got 'stuck'.

DELETE FROM variable WHERE name = 'cron_semaphore';
DELETE FROM cache WHERE cid = 'variables';