Overview
Drupal 6 has a long-standing bug in the block module (as of 5/10/2011). This bug affects block caching mechanisms. The bug manifests itself if you have block caching enabled.
Once a module's blocks have been registered with the system (in the {blocks} table), the block's caching mode settings are never updated in the {blocks} table, regardless of subsequent cache flushes or other system updates. This is only a problem for modules that change the 'cache' info returned from hook_block op='list' calls.
Uninstalling and re-installing the module won't fix the problem due to another Drupal 6 bug.
More info
This problem impacts any module that changes the caching mode returned in hook_block('info') operation. In particular, the views module allows you to edit a block view's caching mode after creation, but, due to this bug, the changes will never take effect, leading to much head-scratching.
More info
The fix
There are a few core patches available (see Issue 235673, above), but they may not apply cleanly to your Drupal 6 installation; I don't patch core unless there's a critical need. In this case, the patches failed to apply on the sites that needed the fix. So I created a simple custom module that implements the guts of the most recent patch.
Note: You can download the module in the Attachments section, below. Leave a comment if you find this module useful, or, if you have questions about it.
This module demonstrates a technique you can use to correct the problem while waiting for a bugfix to be backported into the Drupal 6 codebase. Once installed, it will automatically update each installed block's caching setting in the {blocks} table whenever the caches are flushed. (You can flush the drupal cache manually using the contributed Devel module or the Admin Menu module, or by visiting the Performance settings page and clearing the cached data).
If you decide to install it, follow the standard instructions for module installation. There are no admin settings or other user interface pages for this module. The module updates the {blocks} table automatically whenever the caches are cleared.
Diagnostic logging
The module creates Watchdog log notice entries whenever it updates the {blocks} table, if the variable block_cache_mode_rehasher_verbose is set to true (it's false by default). There is no interface for changing this, but you can use Drush's vset commands:
Enable verbose logging:
drush vset block_cache_mode_rehasher_verbose 1
Disable verbose logging:
drush vset block_cache_mode_rehasher_verbose 0
The watchdog entry looks something like this example:
| Item | Data |
|---|---|
| Type | block_cache_mode |
| Date | Thursday, May 12, 2011 - 13:28 |
| User | {some-user-name} |
| Location | http://example.com/admin_menu/flush-cache?destination=admin%2Fbuild%2Fmodules |
| Referrer | |
| Message | Block cache setting updated. Module: relatedlinks Delta: 3 was: -1 now: 4 |
| Severity | notice |
| Hostname | {some-ip-address} |
| Operations |
How I created the module
I cloned the block module's _block_rehash function, stripped out the irrelevant original code, and inserted the patch's new code that updates the {blocks} table's 'cache' column when the block's reported caching mode changes. Then, I implemented the patch's hook_flush_caches callback, invoking the {blocks} table updater function when the caches are cleared.
Disclaimer
THIS MODULE IS PROVIDED FOR EDUCATIONAL PURPOSES ONLY, AND IS PROVIDED WITHOUT ANY WARRANTY OR GUARANTEES AS TO FITNESS FOR ANY PARTICULAR PURPOSE. USE AT YOUR OWN RISK.
Downloading, distributing, and/or installing this module signifies your acceptance of the terms of this disclaimer.
For more information, see the LICENSE.txt document included with this module.
| Attachment | Size |
|---|---|
| block_cache_mode_rehasher-6.x-1.x-dev.tar.gz | 8.19 KB |
