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 statusWhoa, 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 statuswe get
drush @dev statusPhew. 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.phpNow 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.phpNow to run a command across all of my site aliases I can simply use the @all alias.
drush @all statusYou 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 statusOne 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?