I recently posted my top 10 Drush commands. In the blog post comments, over email and Twitter, a bunch of people let me know their top commands and tips. This was such great feedback, I decided to write up the list as another post. Here is the top 10 Drush commands from the fine folk who contributed (in some cases, they are variations of a command that I listed in my post).

pm-update –pipe (up –pipe)

pm-update will go ahead and update your code and run database updates. But there may well be some special requirements when upgrading a particular module that you need to be aware of and simply running pm-update could be dangerous if you don’t check first.

So how do you get a list of what it will update first, before actually performing the update? Add the pipe option, and you will then get a nice list.

You can then go to the drupal.org project page for each module that needs updating and have a read of the release notes before doing the actual update.

Here is an example of what you get after running the command:

drupal 7.23 7.26 SECURITY-UPDATE-available
backup_migrate 7.x-2.4 7.x-2.8 Update-available
backup_migrate_dropbox 7.x-1.0-alpha1+4-dev 7.x-1.0-alpha1 Update-available
context 7.x-3.0-beta6 7.x-3.2 SECURITY-UPDATE-available
ctools 7.x-1.2 7.x-1.4 SECURITY-UPDATE-available
geshifilter 7.x-1.1 7.x-1.2 Update-available
google_authorship 7.x-2.0-beta1 7.x-2.0 Update-available
hierarchical_select 7.x-3.0-alpha5 7.x-3.0-alpha6 Update-available
inline 7.x-1.x-dev 7.x-1.x-dev Update-available
libraries 7.x-2.1 7.x-2.2 Update-available
markdown 7.x-1.1 7.x-1.2 Update-available
metatag 7.x-1.0-beta4 7.x-1.0-beta9 Update-available
mollom 7.x-2.7 7.x-2.9 Update-available
views 7.x-3.5 7.x-3.7 SECURITY-UPDATE-available
xmlsitemap 7.x-2.0-rc2 7.x-2.0 Update-available                

Thanks to James Oackley for this tip.

watchdog-show –tail (ws –tail)

Running watchdog-show will return a list of messages from watchdog. You can take this further by viewing messages in real time, as they are being recorded with the tail option.

I find this is particularly helpful when debugging. You can add a call to watchdog in your code and with watchdog-show –tail running, see the message appear as you load a new page.

If you get a lot of messages appearing, you can isolate messages from your module.

First, give your watchdog call a unique type:

watchdog('my_unique_type', print_r($variable, true));

Then in the command, use the –type option to isolate messages with the name ‘my_unique_type’:

watchdog-show --tail --type=my_unique_type

watchdog-show –tail was mentioned by an anonymous commenter.

drush archive-dump (ard)

drush archive-dump will backup your code, database and files (from the files directory) into a single file.

Use the destination option to tell it where to put the backup file. For example:

drush ard --destination=/var/www/site/backups/example.tar

Thanks Agnar Ødegård and Jean-Francois Bohemier for recommending this command.

drush sql-dump > dumpname.sql

drush sql-dump will perform a dump of the database. It is similar to what you will get from running mysql-dump.

You can save it to a particular location using the result option:

drush sql-dump > dumpname.sql --result=/var/www/site/backups/example.sql

You can compress the file with the gzip option (a gzip program must be specified in your path):

drush sql-dump > dumpname.sql --gzip --result=/var/www/site/backups/example.sql

If you don’t want to add the result option in everytime, you can add it to a drushrc.php file:

$options['result-file'] = '~/Desktop/@DATABASE/@DATE.sql';

Thanks to Agnar Ødegård for suggesting drush sql-dump > dumpname.sql, Mike Raichelson for the —result-file option and Capi Etheriel for the gzip option and drushrc.php.

drush sql-cli (sqlc)

drush sql-cli will open the sql command-line interface, using the site credentials specified in settings.php.

You can also use this command to restore a database dump: drush sql-cli < dumpname.sql

Thanks to Agnar Ødegård for recommending sql-cli.

drush sql-sync

drush sql-sync will sync your local DB with what’s on the live server.

Thanks to Mike Keran for recommending sql-sync. Check out his article on making sql-sync safer

drush fn-hook (fnh)

drush fn-hook will tell you which modules on your site have implemented a specific hook.

For example, find which modules implement hook_form_alter:

drush fn-hook form_alter

This will return a list of modules, like so:

Enter the number of the hook implementation you wish to view.
 [0]  :  Cancel      
 [1]  :  block_class 
 [2]  :  context     
 [3]  :  inline      
 [4]  :  metatag     
 [5]  :  mollom      
 [6]  :  token 

Select one to see the modules actual implement of hook_form_alter. After selecting [1] block_class, you will get this:

// file: /home/blair/befused/www/sites/all/modules/contrib/block_class/block_class.module, lines 63-78
 * Implements hook_form_alter().
 * Alter block edit form to add configuration field.
function block_class_form_alter(&$form, &$form_state, $form_id) {
  if (user_access('administer block classes') && ($form_id == 'block_admin_configure' || $form_id == 'block_add_block_form')) {
    // Load statically cached block object used to display the form.
    $block = block_load($form['module']['#value'], $form['delta']['#value']);

    $form['settings']['css_class'] = array(
      '#type' => 'textfield',
      '#title' => t('CSS class(es)'),
      '#default_value' => isset($block->css_class) ? $block->css_class : '',
      '#description' => t('Customize the styling of this block by adding CSS classes. Separate multiple classes by spaces.'),
      '#maxlength' => 255,

    $form['#submit'][] = 'block_class_form_submit';

Thanks to Mike Keran for this command. As he mentions it is particularly helpful if you suspect a module is implementing a hook which is altering your code.

drush user-login (uli)

drush user-login will display the one-time login for a particular user. You can use that to quickly login to a site as that user if you need to test something.

Thanks to Raph for recommending drush user-login.

drush pm-updatecode (upc)

I have talked about drush pm-update in my top 10 Drush commands post. This updates module and core code and runs the database updates, all with the one command. But some people prefer to update the code separately to performing the database update. You can do that with drush pm-updatecode. After you have run it, you can check to see what has changed before you touch the database. If your code is under source control, then that is just a matter of running something like git diff before committing.

Thanks kiwimind for this tip.

##drush grep command or drush –filter=command

Most of us don’t have photographic memories, so can’t remember every single Drush command. If you just run the command drush, you will get a list of every drush command available to you. That is a long list, but you can narrow it down if you have some idea of the command you are looking for by adding in the grep command with a pipe in between (a pipe allows you to take the output from one command and use it as input for another command).

For example, let’s say you are looking for all commands that contain the word “user”:

drush | grep user

This will return a nice list of all commands that contain the word user. It will also look in the description, so if a command that doesn’t actually have user in the name, but has it in the description, that will show up too.

You can use the –filter option instead of grep. This will filter by command name only, so will not match against the description (this may or may not be desirable for you).

drush --filter=user

These examples are the equivalent of using the help command: drush help | grep user drush help –filter=user

Thanks Michael Prasuhn for the grep and filter tip.


Pere recommended this great resource for Drush Commands by Peter Brady. It includes commands from many contrib modules as well as core modules.


Thanks for everyone who contributed to this list!