Drush is a great tool that every Drupal developer should learn. It will save you tons of time with everything from downloading and enabling modules, to exporting and reverting Features. Another advantage of Drush is that it allows you to group together commands in simple shell scripts. One of the most common tasks that can be encapsulated in a shell script is synchronizing the current state between to versions of your site. This is commonly done to bring live content from your production site into your development or local site. In this example I will be building a shell script that runs on Mac OS X but it should work on Linux and with small changes probably Windows too.
To take advantage of the Drush commands to synchronize sites you will need to set up Drush aliases for your sites. If you don't know what Drush aliases are you can read about them here. The Drush aliases example file is also a good resource. For our example we are going to use site aliases, @mysite-live, the live version of our site, and @mysite-dev, the development version of our site. Once you have the Drush site aliases setup the first command that we will need is sql-sync. As you might expect this command syncs the databases between two Drupal sites. In our case we would invoke the command this way:
drush sql-sync @mysite-live @mysite-dev
It's that simple. Now your development database will be an exact copy of your live database. It is important to note here that the second site alias is our target site. This is important because you don't want to send your development database to your live site! Luckily Drush asks for conformation before it runs sql-sync so we are prompted to make sure we put the aliases in the right order.
There maybe some problems though with having your development database be the exact same as your live database. You may want certain modules to be configured differently in development than in your live site. Luckily most module configuration settings are stored in Drupal variables and Drush can read and set these variables. Often the file system configuration for your Drupal site will be different on your development and local site than in your live site. In this case you want to make sure that your development settings aren't overwritten by your live settings. This can be done easily by saving the values before you synch the database and then restoring them afterwards.
# Save file system settings private_path=$(drush @mysite-dev vget --format=string file_private_path) public_path=$(drush @mysite-dev vget --format=string file_public_path) temp_path=$(drush @mysite-dev vget --format=string file_temporary_path) # Synch Database drush sql-sync @mysite-live @mysite-dev # Restore File system settings drush @mysite-dev vset file_private_path $private_path drush @mysite-dev vset file_public_path $public_path drush @mysite-dev vset file_temporary_path $temp_path
You also might have modules that you don't want enabled in development and others you only want enabled in development. To solve this problem you can enable and disable modules in your script. In this example lets enable the MailLog and Devel modules. After that lets set the variables related to the MailLog module so that emails are not sent from the site but displayed on the screen. This will ensure that no emails are sent to real email addresses of the users of the site.
drush @mysite-dev en maillog -y drush @mysite-dev en devel -y drush @mysite-dev vset --format=integer maillog_send 0 drush @mysite-dev vset --format=integer maillog_devel 1 drush @mysite-dev vset --format=integer maillog_log 1
Since you will be replacing your development database completely there is a chance that you may wipe out some work you have been doing. Any configuration such as Views, Panels, or Rules that you have not exported out of your development site will be wiped out when you synch with the live database. Of course you know this and won't synch the database until you have all that taken care of, right? Just to be on the safe side it is a good idea to back up your database before you do the sync. If you are using the Backup and Migrate module you can just put this line at the top of your script.
drush @mysite-dev bb
Now that your development database has been backed up, if you had forgotten that you didn't export a particularly complicated View in development you can restore the database to export this View.
Ok, that takes care of syncing your database and updating modules and configuration. In certain cases you may also want to sync your files directory. If your site contains tons of uploaded file attachments you may want skip this step. Syncing the files directory though is very simple via Drush using the rsync command.
drush rsync @mysite-live:%files/ @mysite-dev:%files
This requires you have your files directory defined in your site aliases. As a variation on this you could also only sync certain sub directories of your files directory.
One last thing I like to do in my script is to clear all my caches in my development site.
drush @mysite-dev cc all
Thats it, you're down. You can download the script file to try it out. Of course you may want to add some other Drush commands that you need for your particular workflow but this should get you started.