Auto Disable Cache/Aggregation/Compression On A Drupal Development Environment

Are you currently using Drush (or manually) importing a production database to your development and staging database on a regular basis. Then you tediously going into your performance settings and disabling the cache, aggregation, and compression manually?


Caching mechanisms you have in production can be great until you spend an hour troubleshooting your development environment just to realize you’ve been scratching your head looking at page cache. We’ve all been there. Sure, you can go in and adjust settings manually, but that’s 5 minutes you don’t need to spend everyday, not to mention forgetting to do so when you’re so intent to dive into a new module or problem you’re troubleshooting.


The solution is to use Drupal’s built in $conf variable in /sites/default/settings.php to force set a sites caching configuration. Note the code below will work in Drupal 5, Drupal 6, and Drupal 7. It won’t harm anything if you set a variable that doesn’t exist so I’ll typically paste this across any version of Drupal I’m using.

$conf = array(
'cache' => '0',
'preprocess_css' => '0',
'preprocess_js' => '0',
'block_cache' => '0',
'page_compression' => '0',

While we’re at it, we should add in easy access to perform database upgrades by setting $update_free_access to true.

$update_free_access = TRUE;

Added To Your Workflow

The idea is to couple this code with a development workflow. Obviously you never want to put this in the settings.php in a production site. See Development Workflows With Different settings.php Across Environments. Once you have that working you can toss this code at the end of your settings_override.php file.

Accessing Other Variables

If I missed anything you can add a field to the $conf array on your own by looking at the source code on the /admin/settings/performance (Drupal 5/6) or /admin/config/development/performance (Drupal 7) pages. Take “Cache Blocks” for example. The ID on that input field is “edit-block-cache”. Two simple things you always need to do:

  • Remove the “edit-” portion.
  • Replace dashes with underscores.

That will give you “block_cache” which is your array key. Zero and one are the options since its a checkbox (on/off). Select boxes are just as easy. Take the edit-cache-lifetime option for example:

<select id="edit-cache-lifetime" class="form-select" name="cache_lifetime">
  <option selected="selected" value="0">none</option>
  <option value="60">1 min</option>
  <option value="180">3 min</option>
  <option value="300">5 min</option>
  <option value="600">10 min</option>
  <option value="900">15 min</option>
  <option value="1800">30 min</option>
  <option value="2700">45 min</option>
  <option value="3600">1 hour</option>
  <option value="10800">3 hours</option>
  <option value="21600">6 hours</option>
  <option value="32400">9 hours</option>
  <option value="43200">12 hours</option>
  <option value="86400">1 day</option>

Same principals apply, except use one of the option values instead of one or zero.

$conf = array(
'cache_lifetime' => '1800',

Not sure why you’d want to do that in a development environment, but maybe you’re setting up a staging or production environment and want to force it in the opposite way there.

Other Methods

To try a be as complete as possible, there are a few other methods you can try out if you don’t like this method for some reason.

  • Cache Disable – This is a module that will disable the cache for you. Of course if you’re automatically pulling your database in you’ll still need to go somewhere and enable this module again since you probably wont want it to be turned on in production. Since you’re likely using Drush to pull the database you could also run drush pm-enable cache_disable after your drush sql-sync call, or in a shell script. But why? Drush already has a command for cache clearing: drush cc all. Much more effort to configure all-in-all. Plus it’s only available for Drupal 5 and Drupal 6.
  • You could create a separate node with some PHP code on it that clears your cache.
  • But the Devel Module already does that and more easily since you can throw the block for it in your side bar (along with other handy utilities). Not automated enough. Before I discovered $conf variable, this was my cache clearing method of choice.

Respond: Leave A Comment | Trackback URL

Entrupeners, Subscribe for the lastest tools, tips, and tutorials.

Leave a Reply

Custom Theme by Rob Malon | Content & Design © 2010 - RobMalon.Com - Chicago, Illinois