by James Sansbury on July 1, 2010 // Short URL

New features in Drush 3

It just keeps getting better. Seriously.

So… Drush. Are you using it yet? If not get drushing!—or whatever you call it. If you're not familiar with it, Drush is a command line interface for Drupal sites. It's the bees knees, if you ask me. You can use it to enable/disable modules, run update.php, get a SQL dump of your site, and all sorts of other magically delicious things. The problem is, it just keeps getting better. I almost can't keep up with it! The recent release of Drush 3 includes all sorts of goodies, and every day I seem to find more and more. I'm going to take a quick look at a few of them that I'm most excited about.

Drush remote capabilities

One of the awesome new features in Drush 3 is the ability to run Drush commands on a remote server. So, I can run commands on a remote site without having to manually connect to that server. In order for this to work, you'll need to have Drush on the server as well as your local machine, and you probably want them to be the same version as well. You'll also need to be able to ssh to the server using key authentication. Check this out:

drush /path/to/drupal#mysite.com status

Whoa, ok, so this is cool, but it looks kind of daunting, doesn't it? To break it all down, this is running drush status as the username user for mysite.com, which resides on myserver.com in the /path/to/drupal directory. Clear as mud, wouldn't you say? :) If it looks to be too much for your CLI tolerance, this will get easier with the next section on Drush site aliases. The magic here is that this command is run on a remote server. Wow!

Drush site aliases

Another amazingly awesometastic™ new feature in Drush 3 is that of site aliases. Site aliases are essentially a way to shorten that whole mess you saw above, so we don't have to type that crazy long string every time we need to run a command for that site. So, instead of this:

drush /path/to/drupal#mysite.com status

we get

drush @dev status

Phew. That's so much better, don't you think?

So how do we get this set up? To get started, we're going to create an aliases.drushrc.php file and place it in the .drush directory inside our user's home directory (~/.drush). There are other ways to specify aliases which you can read about in the awesome documentation.

# If the .drush directory doesn't exist, go ahead and create it.
mkdir ~/.drush

# Now we create the aliases.drushrc.php file.
touch ~/.drush/aliases.drushrc.php

Now open this file in the editor of your choice and we'll add a site alias for a dev site.

<?php
$aliases
['dev'] = array(
 
'uri' => 'localhost', // Replace localhost with the uri of your site
 
'root' => '/Users/jsansbury/Sites/dev', // This is the Drupal root directory.
);
?>

That's it! Now if I want to run a drush command on my local dev site, I can type (from any directory) drush @dev [command] and it will just plain work. Gotta love that! Let's keep going and set up aliases for some remote sites:

<?php
$aliases
['dev'] = array(
 
'uri' => 'localhost', // Replace localhost with the uri of your site
 
'root' => '/Users/jsansbury/Sites/dev', // This is the Drupal root directory.
);
$aliases['stg'] = array(
 
'uri' => 'stage.example.com',
 
'root' => '/var/www/example.com',
 
'remote-host' => 'stage.example.com',
 
'remote-user' => 'username',
);
$aliases['live'] = array(
 
'uri' => 'example.com',
 
'root' => '/var/www/example.com',
 
'remote-host' => 'example.com',
 
'remote-user' => 'username',
);
?>

Great! Now I can run commands on a remote site without having to log in to that server, and without having type a huge long string that only makes sense to less than 1 percent of 1 percent of the world (those same people are wondering why I didn't just write < 0.01%). Now, if we could somehow run commands on groups of sites, wouldn't that be cool? Like running drush update-db (essentially executing update.php) across a slew of sites?

Drush site alias groups

I was just setting you up. See how I did that? [Insert trumpets here] You indeed can run commands across groups of sites. There are a few ways to do this. As of Drush 3.1 we can move our file called aliases.drushrc.php to GROUPNAME.aliases.drushrc.php where GROUPNAME is the name of your group. Let's use 'all' for our group name:

# Move our aliases file so that it has a group prefix.
mv ~/.drush/aliases.drushrc.php ~/.drush/all.aliases.drushrc.php

Now to run a command across all of my site aliases I can simply use the @all alias.

drush @all status

You can have multiple GROUPNAME.aliases.drushrc.php files, each with a different group. Another option is to use the 'site-list' option in the alias. I actually prefer this method—it seems a bit more flexible to me. Let's create a @remote alias that points to all of our remote sites. Open up that all.aliases.drushrc.php file again, and let's add this to the bottom of it.

<?php
$aliases
['remote'] = array(
 
'site-list' => array('@stg', '@live'),
);
?>

I think you know what's coming next. :)

drush @remote status

One additional thing to mention is that you can type drush sa --full to see a list of all site aliases available to you. You'll note that if you run this command on a Drupal multisite platform, it lists the @sites alias, which is actually a group of all the sites for that particular Drupal directory.

The End

Or is it? As you can see, Drush just keeps getting better and better as a development tool for Drupal. I for one am pretty excited about these new features, and they've already sped up my workflow tremendously. What are your favorite new features in Drush 3?

James Sansbury

Development Manager

Want James Sansbury to speak at your event? Contact us with the details and we’ll be in touch soon.

Tags:

Comments

Chris Cohen

Thanks

Excellent article, and very easy to follow. I have tried this myself and Drush 3 is a fantastic step forwards. Thanks for writing this.

Reply

Matthew Oliveira

Drush on Cygwin?

Hey,

Nice article, I've been looking for a way to setup drush on Cygwin on a Windows PC. Has anyone done this or come across an article showing how?

Matt

Reply

Genny Engel

Update core!

New in Drush 3 is the ability to update Drupal core. Up till now, Drush was a huge timesaver for updating modules and themes ... only. To update Drupal itself, you still had to download and install it, set the settings.php back to point to the correct database, etc., etc....

No longer! Now you just back up your data and files, then with the magic two words "drush up" you can bring your entire Drupal installation up to the latest and greatest version. Yippee!!

Reply

Jeff Geerling

Drush == win

I have been using Drush on the largest site I manage (which is also backed up hourly, uses SVN for development, etc. etc...

But until now, using Drush with a multisite Drupal install was about as easy as juggling three CRT monitors (and close to as awkward)!

I just installed Drush on my personal multisite, and updated all modules/themes/etc. in about four minutes instead of my usual hour-long FTP/update.php session!

Reply

The Brainchild

I liiiiike!

One of the Drupal programmers in the office mentioned Drush 3, though I hadn't heard of it before. After a little digging around on Google, well, here I am! :)

Reply

Quaoar

Drush is "ok" and a necessity

A small rant.

Drush is a requirement if running large sites. As such it's a good addon for Drupal. Problem is memory leaking PHP-parser, the memory hogging static variables usage in Drupal, and poor memory handling in Apache/PHP.

Drupal is such an awesome framework. Too bad it's based on PHP =/

Reply

uberhacker

Re: Drush is "ok" and a necessity

OK, so what's the alternative? Instead of bashing PHP and Drupal, please offer a better solution. I bet you can't find one.

Reply

uberhacker

Graceful updates

Nice article James. I'm impressed with the progress of this project. What if I want to set the site offline and backup files and the database before each update? I know drush backs up modules during updates but what about the database? Should this be done with a shell script for each site instead of running updates with a group alias? Also, in the event the unthinkable happens, what about rollbacks? On production sites, a complete change management solution is necessary.

Reply

hairybrew

Great article! You cracked me

Great article! You cracked me up on 1 percent of 1 percent, but then I thought about it too long and thought, did he mean < .0001% or did he mean... then i took an alias pill.

Reply

q0rban

Wow, drush cli!

So, I just discovered the drush cli command as well. With it, you can enter a drush command line interface for a particular site. Check this out:

$ drush @stg cli
Entering the drush cli.  Use CONTROL-D to exit.
Type 'help' for help.
drush> cc all
'all' cache was cleared                                  [success]

That's super handy when you have a series of commands to run for a particular site. :)

Reply

Laura

Bummer

The remote capability and alias feature sounds great, but I just spent half a day trying to figure out the SSH key authentication stuff (client: Mac, servers: Windows) to no avail. The advanced Drush features are still very inaccessible to me as a front-end developer. :(

Reply

q0rban

Yikes

SSH Key auth between Mac and PC! —gasp— No wonder you are having troubles. I'm sorry I don't have any tips for you on that one. :(

Reply

greg.1.anderson

drush cli is a bash subshell

drush cli just opens a bash subshell with some aliases defined; it is by definition interactive only. However, the function of drush cli is to call drush, which is by definition scriptable.

e.g. to duplicate the drush cli example above:

#!/bin/bash

MYSITE=@stg
drush $MYSITE cc all
Reply

William

Scriptable

Yes - since the commands are all run from the shell - you can call these commands from scripts.

Reply

John_Buehrer

drush @site sql-cli ??

Hi, Is this supposed to work? It just hangs from my MacOSX bash shell.

$ drush @mysite sqlc

Drush CLI (bash shell) also fails, although the underlying ssh does work:

$ drush @mysite cli
Cannot run drush core-cli from non-interactive mode; aborting. [error]

$ ssh hostname
server18.myhost.ch

These commands do work:

$ drush @mysite status
$ drush @mysite sql-dump --ordered-dump > mydump.sql
Reply