Things to do after copying a site to your local computer

There are a number of things I usually do after syncing a site to my local computer: enable developer modules, disable css aggregation and caching, etc. It usually takes some time to this every time after syncing, so I have created a simple drush script, that does all the work automagically.

These are the things the script does (except for 0., I always do it manually).

0. Creating a local copy

After setting up a virtual host and a database on my local machine (I'm using a simple shell script for this), I use drush to download a site:

drush rsync @source.alias @destination.alias --include-conf
drush sql-sync @source.alias @destination.alias

I prefer to manually type these commands, just to make sure I'm not accidentally syncing the wrong way...

The --include-conf is only needed when syncing for the first time. It downloads the settings.php which you can update with your local database credentials.

I have also added this default option to drush:

$command_specific['core-rsync'] = array(
  'exclude-files' => TRUE,

So that I won't download the entire files directory. I'm going to use the stage file proxy module instead (see below).

There a number of places to put this code, I've placed it to ~/.drush/drushrc.php. (don't forget to run drush cc drush to update drush)

1. Log in as user 1

Sometimes I don't have access to the user 1 account on a live site, however locally I prefer to do and see things as if I were the admin user. Even if I do have access to the user 1 account, I should keep track of the user names and passwords for all the sites, which could be quite cumbersome if you are managing a bunch of sites, even when using a password manager like KessPassX.

What I like to do is to simply change the user name and password of user 1 to admin/admin. I put this code into a drush script and drush does this for me:

# Change the name for user 1 to "admin".
drush_shell_exec('drush sql-query --db-prefix "update {users} set name=\"admin\" where uid = 1"');
# Reset admin user password to "admin".
drush_shell_exec('drush user-password --password=admin admin');

2. Enable developer modules

There are a number of modules I prefer to have enabled in a local development environment in order to make my job easier:

  • admin menu - makes clicking around in the admin interface a whole lot easier
  • dblog - core database logging module
  • devel - must have...
  • module filter - makes the admin/modules page more user-friendly
  • search krumo - easy searching in arrays and objects printed out with devel
  • stage file proxy - so that I don't have to download the files directory

The script automatically enables these modules, downloads them if needed.

3. Enable UI modules

UI modules might be disabled on live sites and you usually need to enable them on your local machine. Look for this part in the script:

# Make sure UI modules are enabled.
if (in_array('views', $enabled_modules)) {
	$dev_modules_all[] = 'views_ui';

You should be able to easily add your UI modules, e.g. context_ui, just by copy pasting the code and changing the module names.

4. Set views to developer mode

A handy drush command to make small changes in the views UI, e.g. always show the master display or the advanced tab.

if (module_exists('views_ui')) {
	drush_shell_exec('drush views-dev');

5. Disable modules you don't like

Yes, I'm talking about the Overlay module. :)

6. Modify variables

There are some settings stored in variables that usually should be different on development and production sites:

  • page and block caching
  • css and js aggregation
  • display settings of error messages

The script makes sure that caching and aggregation are disabled and all errors are shown on the screen.

Where to find this script?

On my GitHub account, here.

How to use the script?

Quite simple:

  • navigate to a local drupal root folder (I never use it with site aliases, if you accidentally enter a remote alias, you'll be in trouble...)
  • run the following command -y --liveurl=""

That's it, you are done, your site should be ready for development.

Taking it further

You can customize this script further, e.g. disable Minify module or enable additional UI modules. You can also write a similar script that configures a site before it goes live. This could do things like:

  • disable developer and UI  modules
  • enable caching and CSS/JS aggregation, hide error messages
  • enable and configure modules that makes the site faster, e.g. Boost, AdvAgg, etc. (AdvAgg has a bunch of variables that is very convenient to set using a script)


Drupal theming and sitebuild

  • PSD to Drupal theme
  • Installing and configuring modules (Views, CCK, Rules, etc.)
  • Theming modules' output

Drupal module development

  • Almost every site needs smaller modules to modify HTML output or override certain default functionalities
  • Developing custom modules

From the blog