Advanced Drush at Drupalcon Chicago


Team Based Drush

When you need to start from scratch, you can blow away what you have with drush site-install -y welcom

What did we really do here? You can also use drush si --yes welcom. Welcom is an installation profile that we created for this project. This command installs Drupal according to the install profile.

If one of my teammates needs a module, he can put it into the install profile file, commit it, and then when I get his commit I'll get the module too.

I want to show drushrc.php. I didn't have to type the argument 'welcom' myself, because it's in the drushrc. I've inputted the site name, site mail, account name, account mail and account password. This way, you don't have to remember these options when installing Drupal. I put that file into the root of my site. You'll see it at the same level as index.php and install.php. All of your developers will have this file, which is a centralized place for options. This is great for a team-based workflow.

We also have a that executes a number of drush commands, and we encourage you to do this as well.

Let's say we've gone live and we have user data that we want to preserve. Sql-sync is a drush command that takes a database from one site and moves it to another site. For example: sql-sync @prod @alice --sanitize

Here's another example: git pull
sql-sync @prod @local --sanitize
drush updatedb
drush features-revert

SQL Sync does:

  • cache check - you can disable this if you don't want it. It assumes that if I've done a mysqldump within the last 24 hours, don't do it again.
  • generate table list - Some tables will never be dumped
  • sql-dump
  • rsync - The file is kept on the developer desktop, so we're only moving the difference since the last time you got it. This moves very big DBs pretty fast.
  • import
  • sanitize


This allows you to take the emails and passwords out of the database that the developer is receiving. This overwrites them with anything you want, usually something like It also changes the passwords. There's a hook, hook_drush_sql_sync_sanitize() that allows you to override the drush sanitization for your custom module to scrub the data more thoroughly. This option is one that you should hardcode in the drushrc.php.


This allows you to set 'shortcuts' to your different environments, such as the host and Drupal root directory of a remote site. You can have inheritance in your site aliases, using the 'parent' => '@demo.base' syntax. The 'demo' corresponds to the prefix of the demo.aliases.drushrc.php file.


There are a lot of hooks in the drush invocation process where you can plug in and deny an operation. For example, you can deny sql-sync to the production environment.

Write your own drush commands

I like to write commands for the development team because they can quickly figure out the arguments and structure, and the members of your team know how to look up all of this stuff. When you write a command, it shows up when people run drush help Commands have dependencies, validation and rollback, which many simple drush scripts just can't do.

Scripting with drush

For example, drush @d7 fieldinfo fields --pipe will export all the fields on your site.

drush @d7 user-information --pipe 1,2,3 will export the user information for the site.

Here's a really great trick: drush @d7 mysql-cli will open up a mysql command prompt without you having to look up the username and password. Similarly, drush @d7 sql-connect will output the mysql command that will connect you to the database.

Running a PHP script with drush is a little different than running on its own; through drush, the site is fully bootstrapped, and you can do anything you can do on the live site. Load a node, set the title, print a message. It's great for an ad-hoc thing where you want to try something difficult. I ran this command: drush @d7 scr kittens.php 2 4 6

Another alternative in Drush 4 is a native script, that is, an executable file. The real difference is the start of the file. Rather than a PHP open tag, we have #!/usr/bin/env drush. It runs in exactly the same way, but from an end user point of view, it just looks like a native executable.

Scripts are great for little tasks, but for larger chunks of code, the error handling is pretty bad. If you do want to build something more sophisticated, you need to run a command.


Moshe went over some of the advantages of commands. It's pretty easy to get going, and it gives you a lot more options and flexibility. Those of you here last year will remember the drush make me a sandwich command.

drush xkcd will run my custom 'xkcd' command, and a small help file to assist people using it.

A command is a little like a Drupal module. It's running in a different environment, but the way it's invoked is very similar. Each command is kind of like a page callback. Here my command name is $items['xkcd-fetch'] = array(... then, we'll write our function function drush_xkcd_fetch($search = '') {... In this case, the function pings the xkcd site and manipulates the response. You can do pretty much anything you can do in a standard Drupal command. This was particularly easy because Xkcd has a JSON API.

Future of Drush

Git works in Drush 4.3 and 5.x! Here are things that don't quite work yet:

  • Issue queue commands don't work yet. We're working on it.
    drush iq-info 1070558
    drush iq-apply-patch 1070558

    There's also a command to post a comment on an issue queue.

  • Cache commands
    drush cache-set blah "blah string"
    drush cache-get schema --format=json

  • Node commands very experimental!
    drush entity-show 1 | bcat will give you a printout of the node;
    drush entity-show 1 --json | bcat
    drush entity-edit 1 | bcat will allow you to edit enties
    Who knows how this will work in the wild! We need to test this. If you're wondering why people would use this, that's a sane thing to think. But check this out:

    drush entity-show 1 --json | drush entity-create - just copies the node. So if you use this, you could dump a node from your local machine and then import it on a remote drupal instance. I'm not suggesting drush should be a workflow for content deployment, but the possibilities are there and we need people hammering on it and work to be done.

  • Parallelization is important when running large scripts on large databases, and this is something that Capistrano does. Right now we have a patch to do this, where it works on some things and not on others. Not a whole lot of work has gone into this so far. That would be a great thing to have in Drush core for Drush 5. The issue is 1053072.

Did you enjoy this post? Please spread the word.