We maintain dozens of Drupal sites for our clients, in a wide variety of hosting environments. Keeping all of these sites up to date could be a nightmare, but our job is made much easier thanks to the awesomeness that is Drush.
If you manage a site, but haven't yet dipped your toe in the world of command-line, site management. We created this short list of useful drush functions to get you started. When you see how easy, and powerful it is, we think you'll be hooked.
Drush, the DRUpal SHell, is a command line utility that lets you perform all kinds of Drupal tasks more quickly and efficiently than you can by clicking your way through the UI. Especially if you’re a fast touch typist – which I’m not this week, thanks to a woodworking accident last weekend. But that’s another blog post, for a different blog.
This won’t be a complete tutorial on how to install and use Drush, because there are plenty of great tutorials out there already. Instead, I’ll talk about some of the ways we use Drush here at 4Site to streamline our site maintenance workflow.
1. Drush Aliases
Drush would be awesome even if we had to SSH into every site separately. But we don’t, thanks to Drush site aliases. A Drush site alias is just a short snippet of PHP code that tells Drush how to log into a remote site using SSH. It looks something like this:
$aliases['mysite'] = array(
'remote-host' = 'live.mysite.com',
'remote-user' = 'drupal',
'root' = '/var/www/html',
'uri' = 'www.mysite.com',
If I save that code to a file called aliases.drushrc.php inside the .drush directory in my home directory on my local machine, I can then type a Drush command, adding a reference to the remote site alias, and my command will be executed on the remote site. If I wanted to get the status of mysite, I’d type:
drush @mysite status
That’s much faster than logging in to the server!
Creating an alias file is pretty easy, but our main hosting provider, Pantheon, makes it dead simple. On the Pantheon dashboard, there’s a “Download all Drush aliases” link. Putting that file into my ~/.drush directory creates site aliases to the DEV, TEST, and LIVE environments for every Pantheon site I work on!
2. Updating Core
On Pantheon, it’s easy to apply core updates with just a couple of clicks from the dashboard. But if I’m already in a shell, I can use Git to update my local development copy of the site, pulling from Pantheon’s upstream repository on GitHub (which contains Drupal core plus several Pantheon-specific customizations):
git pull git://github.com/pantheon-systems/drops-7.git master
git push origin master
I probably wouldn’t really do this – in this case, using the dashboard is easier. But I might put it in a script someday, so we can update core on all our sites with one command! On non-Pantheon sites, updating core is still simple using Drush:
drush @mysite up drupal
3. Updating Modules
Updating contrib modules is easy, too. On Pantheon, we first have to put the site into “On-Server Development” mode so that Drush can write to the filesystem directly. To update everything at once, we can just type drush pm-update. But I like to have a little more control. First, let’s get a list of all the modules that have available updates:
drush up –n | grep available
The –n answers “no” to Drush’s “do you want to update?” prompts, then grep filters the output to just give us lines that include the word “available,” leaving us with a list of modules with available updates that looks something like this:
Date 7.x-2.5 7.x-2.6 Update available
Organic Groups 7.x-1.4 7.x-1.5 SECURITY UPDATE available
Rules 7.x-2.1 7.x-2.2 Update available
Token 7.x-1.3 7.x-1.4 Update available
Views 7.x-3.3 7.x-3.5 Update available
The update to Organic Groups is a security update, so I’ll probably want to perform that one right away. But let’s say we want to hold off on updating Views for some reason. Perhaps we applied a patch to fix a bug, but we know that patch hasn’t been committed yet. So let’s update everything but Views. We just add the machine name of each module to the drush up command:
drush up @mysite.dev date og rules token
When the updates are done, we have to take the site out of On-Server Development mode, then type a commit message when prompted by the Pantheon dashboard.The drush up command (actually a shorthand version of drush pm-update) will automatically perform any required database updates. But if we want to do the database update separately for some reason, Drush makes that easy, too:
drush @mysite.dev pm-updatecode module1 module2 ... moduleX
drush @mysite.dev updatedb
Other Common Maintenance Tasks
There are lots of other things Drush can do. Here are just a few of the commands I use frequently:
Clear all caches: drush @mysite cc all
Rebuild the search index: drush @mysite search-reindex
Show recent log messages: drush @mysite watchdog-show
Show detailed info for a module: drush @mysite pm-info modulename
Disable a module: drush @mysite pm-disable modulename
I don’t use the following commands nearly as much as I used to now that most of our new site development is on Pantheon, but they’re still useful for our older sites in other hosting environments:
Sync database and code from TEST to LIVE:
drush db-sync @mysite.test @mysite.live
drush rsync @mysite.test @mysite.live
Back up the database:
drush @mysite.live sql-dump –result-file=
Restore database from a backup:
drush @mysite.dev sql-connect <
Spinning Up a New Site
4Site has a "base install" that contains Drupal core, our base theme, our go-to modules, and the basic content types, views, and other configuration that we use on most of the sites we build. Spinning up a new site that uses this base install is easy, thanks to the drush make command and a “makefile” that we store on Dropbox. Look for a blog posts in the coming weeks with more on our base install.