A hackish module to avoid many cache wipes/flushes/clears in Drupal.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
This repo is archived. You can view files and clone it, but cannot push or open issues/pull-requests.
Bèr Kessels 2364fb30d1 spellcheck 10 years ago
README.md spellcheck 10 years ago
cache_delayed.inc table is a reserved word. 10 years ago
cache_delayed.info made part of Caching package in info file. 10 years ago
cache_delayed.install initial code. Untested and prolly not working. 11 years ago
cache_delayed.module Cron callback fixed: bug in auth logic and auth function was not always available. 10 years ago
cache_delayed.override_all.diff example patch (that might not work at all) for how to override /all/ cache-clears. 11 years ago


Delayed Cache module

Provided by Dutch Open Projects Developed by Bèr Kessels


A simple module that allows certain cache_clear_all() calls to be delayed. Requires core hacks. only for certain For experienced Drupaleers only :) (it has severe side-effects, such as a much better working cache, or a broken site).


  • A site with commenting only for authenticated users will wipe cache for anonymous users every-time a comment is saved.
  • A site where you want to enforce cache for a longer period, despite you (or other authenticated users) writing articles.
  • Any other site where you have problems building up a proper cache for blocks, pages and such, because it gets flushed by several (core) actions.

Installation and usage:

  1. Install the module in the regular way. It will not do anything yet.
  2. Include the cache_delayed.inc file in settings.php (needed to have functions available on lower bootstrap moments) require_once('./sites/all/modules/custom/cache_delayed/cache_delayed.inc');
  3. Create, or think up a token. Secure tokens can be made (on *nix) with the command uuidgen.
  4. Add a token to your settings.php variables. This token grants access for cron. Keep it secret. $conf = array( …other conf might be set already. ‘cache_delayed_token’ => ‘s3cr3t-h3r3’, );
  5. Use this token in a cron call. Every time this cron is ran (or more accurate: the URL is called) the queue is walked trough and all caches are cleared. You could set this to run every 10 minutes, for example. curl --silent --compressed http://example.com/cache_delayed_remove/s3cr3t-h3r3
  6. In the places where you want to avoid a cache_clear_all() , replace with cache_delayed_clear_all(). Calling the latter, puts a new to-be-cleared in the queue, which will be actually cleared on the next cron run.

How it works:

Every time a cache_clear_all is invoked, instead of clearing the cache, it will add an entry to a worker queue. When calling a (secured) URL, we walk trough the queue, select those entries “old enough” and wipe them from your cache (and remove them from the queue).

Why it was made :

For a certain site, we saw over 1000 queries to build pages. One quick-fix was to use the cache better. Drupals caching system however, is brokennot very smart. And will flush on every comment posted, node created, poll-voted and so on. We wanted to avoid these wipes, by enforcing the cache to remain un-flushed for a little longer. Even if Drupal is stubborn and wipes it anyway.

The other option was to build the site in a proper framework :) And the last option, is to simply fix that ridiculous amount of queries. But that is the long route.

Core hacks

You have two options.

  1. Hack the actual cache_clear_all in core, so that /all/ cache_clear_alls go via the queue. This will have many side-effects. So know what you are doing.
  2. Hack certain places where cache_clear_all is called, for example comment_save(), to avoid a full cache-wipe only in that place. Has little side-effects.


Cherry-picking: Allow URL-parameters to wipe cache with a CID, in one table or with a wildcard only.


Few. We opt for speed, not flexibility.


We insert, delete and update with delayed and low_priority. Thus only works on databases that support that. And the resulting status can most often not be used at all. After all: mysql may wait with inserting a broken or duplicate record, but never report this brokenness or duplicateness back to our code. Keep an eye on the logs. Use the Logs Luke. Use the Logs.