When faced with a repetitive development task I like to throw a bash script at the problem. And nothing elevates the power of a bash script in Drupal development more than using Drush.
Drush is a command line tool for managing a Drupal site. It’s a developers best friend. But the real power of Drush is in writing your own custom Drush commands.
Whenever I start a new Drupal project I drop in a special Drush command I wrote to quickly make a local installation developer friendly. I call it drush golocal. This command enables developer friendly modules like Devel, Stage File Proxy, and Views UI, enables email rerouting so your local install doesn’t send emails to users, disables a bunch of internal Drupal caching, and sets some helpful permissions.
I place this code in a custom module in a special include file where drush looks for commands: EXAMPLE.drush.inc.
<?php /** * @file * Custom Drush integration. */ /** * Implements hook_drush_command(). * * @return * An associative array describing your command(s). */ function EXAMPLE_drush_command() { return array( 'golocal' => array( 'description' => dt('Puts your site in local development mode.'), ), ); } /** * Put the site in local development mode. */ function drush_EXAMPLE_golocal() { // Enable dev friendly modules. module_enable(array('devel', 'reroute_email', 'dblog', 'update', 'diff', 'field_ui'), TRUE); // Disable any production modules that you don't want to run locally, like // CDN. $disable = array(); module_disable($disable); drush_log(dt('Modules disabled: @modules', array('@modules' => implode(', ', $disable))), 'ok'); // Make sure the rerouting of email is turned on so we don't send emails to // actual users from our local installations. if(module_exists('reroute_email')) { variable_set('reroute_email_enable', 1); variable_set('reroute_email_address', '[email protected]'); drush_log("Email is being rerouted to [email protected].", 'ok'); } else { drush_log('Emails will be sent to users!', 'warning'); } // Allow everyone to see devel messages like dpm(). if(module_exists('devel')) { user_role_grant_permissions(1, array('access devel information')); user_role_grant_permissions(2, array('access devel information')); } // Set some dev-friendly settings variable_set('cache', "0"); variable_set('block_cache', "0"); variable_set('error_level', "2"); variable_set('preprocess_js', "0"); variable_set('preprocess_css', "0"); variable_set('page_compression', "0"); drush_log('Page cache, page compression, JS optimization, and CSS optimization disabled.', 'ok'); drupal_flush_all_caches(); drush_log('All caches cleared.', 'ok'); drush_log('Site ready for development!', 'ok'); }
As development continues (and after launch for support), this is the perfect place to add site-specific changes that relate only to that project (such as switching to development instances of third-party systems to which your site connects).
Bonus Points!
Now that you have a handy way to put a site into development mode in your local installation, consider integrating this script into your dev/stage/production workflow. If you use a platform like Acquia Cloud that provides deployment hooks, you can have this routine run every time you copy the production database to the dev server automagically.
You can even take it a step further and write a bash script that downloads a copy of the production database, imports it into your local install, and then runs this command. Suddenly you can update your local environment from production and have it ready for development with one simple command.