My top 10 Drush commands

Drush is awesome. Having Drush commands at my finger tips saves me a lot of clicking in the Drupal admin interface and ultimately makes me more productive. If you are new to Drush, you might find the large number of commands available overwhelming and not know which ones to start with. Here are the 10 Drush commands that I use most often - the ones I use every single day when developing Drupal sites.

1. clear-cache (cc)

When you are developing Drupal modules, you will often have to clear the cache (for example, when adding a new menu item in hook_menu).
You can clear all caches with drush cc all, or choose a specific one with drush cc

  drush cc all

2. pm-list (pml)

This shows you a list of modules and themes that are available for your Drupal site. When I am working on a site, I often want to know if a particular module is enabled. You can use pml in combination with grep to see if the module you are looking for exists in the site.

 drush pm-list | grep modulename

One of the advantages of using grep is that you don’t even need to know the full module name.

For example:

 drush pm-list | grep media

This will find any module or theme with media in the name. In my case, it returns Media, Media Desk, Media Internet Sources and Multimedia Editorial Element.

3. feature-update (fu)

If you have a Feature and you change something that is stored in that Feature (e.g. you update a View), you will need to update it. This will export the components to code. Rather than manually exporting the feature in the admin interface, you can just run feature-update.

 drush feature-update feature_name

4. feature-revert (fr)

If you decide you don’t want to keep the changes that you have made, you can run feature-revert to bring it back to the code version. This makes it easy to play around with various settings.

 drush feature-revert feature_name

5. updatedb (updb)

This will run any pending database updates. This is normally required if you update module code and that module needs to update the database. This saves you from running updates via update.php.

 drush updatedb

6. variable_get (vget)

I sometimes need to quickly see the value of a particular variable, so variable_get can be a real time saver.

 drush variable_get variable_name

7. watchdog-show (ws)

Rather than going to the watchdog page to see errors and warnings, you only have to run watchdog_show.

 drush watchdog-show

8. pm-download (dl)

I am often downloading new modules to try out. Rather than going to to download them, I just run pml-download with the module or theme name.

 drush pm-download project_name

9. pm-enable (en) & pm-disable (dis)

Once a new module or theme has been downloaded, it needs to be enabled. I do this with the pm-enable command, rather than going to the module page.

 drush pm-enable project_name

If I no longer want a particular module enabled, I run pm-disable. Like pm-enable, it saves me from going to the module page.

 drush pm-disable project_name

10. pm-update (up)

Update Drupal core, modules and themes with pm-update.

 drush pm-update

How about you?

If you use Drush, let me know the commands you use most often.

If you don’t use Drush, let me know what is holding you back. In the near future, I will cover the most common reasons that are preventing some people using Drush but more importantly how to get past them.


That's a good list. I use 6 or 7 of them very often.

One you didn't mention that I use often is "pm-update --pipe".

Obviously, to use plain "pm-update" on its own is very risky, and should certainly never be done on a production site. However when I get an e-mail to say that there are updates for some of my modules and themes, I always want to know which ones. The e-mail doesn't tell you, and it is time consuming to log in to the site as an administrative user and go to the page showing available updates.

Cue "pm-update --pipe", alias "up --pipe". It simply checks all projects for updates, and then displays a list of all those that are due an update. I can then go to the relevant project page on, read the release notes, and plan an update strategy for it.

Blair Wadman's picture

Great tip, thanks!

@James - Agree... very good tip!

@Blair - Great list!

I'm a front-end guy and don't really have to maintain sites directly, etc. But as I expand into more backend skills (like module building, etc)... I find I use drush more and more. Glad I ran across your site Blair. I've bookmarked it and plan to purchase your module development course. Keep up the good work.

Watchdog-show had escaped my attention for some reason. You can apparently even tail it with --tail option so drush ws --tail now belongs to my regular toolbox. Thanks for it!

Blair Wadman's picture

Yeah, I use --tail quite often when coding. For example, I might add a watchdog() call in a custom module to record something. Using watchdog-show --tail is a real time saver!

Same here, wasn't aware of watchdog-show and it will be incredibly handy! Thanks!

I'm working more on big established sites, not so much building from scratch anymore, and I use these commands very, very often:

drush sql-dump > dumpname.sql
drush sql-cli < dumpname.sql

and some times

drush ard --destination=/path/to/someplace/i/like

ard makes a complete db and file backup.

On my to-research list is figuring out how to use aliases to transfer whole sites from one server to another. I think it's possible.

A quick note on drush sql-dump: it actually has a --result-file parameter that you can pass to it rather than needing to manually capture stuff to a file. A la...

drush sql-dump --result-file=~/Desktop/backup-before-exploding-things.sql

Well, while we're at it, let's gzip it!

drush sql-dump --gzip --result-file=~/Desktop/backup-before-exploding-things.sql

And you can set up the file path in drushrc.php and be a slacker for a lifetime:

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

Blair Wadman's picture

Great tips here! Thanks for sharing them.

Great list. I've two more suggestions. Though I don't use they all that often, I find them to be huge timesavers:

drush sql-sync for syncing my local DB to what's on the live server. When I switch back to working on an old project (think maintenance contracts), it comes right after git pull. As we tell our kids, be sure to use protection, as you can also push your local DB to the live server...

drush fn-hook (alias: drush hook will tell you what modules implement a given hook. So if you swear that someone's altering your hook_foo_alter you can type drush hook foo_alter and get a list of all enabled modules that could be culprits. Bonus: type the number next to the result and drush will spit out the implementation in question.

Blair Wadman's picture

Thanks for these, both great suggestions. I have been meaning to use fn-hook for ages.

Thanks for the feature ones.

drush uli (user-login) certainly appear in my own list.
Really useful when you have to manage thousand websites a day.

Blair Wadman's picture

Nice one Raph.

Good list, thanks.

Rather than using drush up, I'm more of a fan of breaking this down in to steps.

drush pm-updatecode (upc) allows you to just update the code, then run the database update afterwards.

Blair Wadman's picture

Good idea


I made a similar post some time ago, and I try to update it when I discover more:

Also, this site is a nice resource:

Blair Wadman's picture

Thanks for the link Pere. I particularly like the boilerplate one from module builder. Haven't used that one in ages.

I discovered the other day. It is really cool.

Blair Wadman's picture

Thanks everyone for your commands and suggestions. There is some awesome stuff here.

Great drush commands, I am new to drush but I am already familiar with most of the list.

@pere, nice link!


When working out why schema aren't panning out quite right, or anything that requires re-installing the module then I use

`drush dre -y MODULE_NAME`

Requires the devel module, it automatically disables, then uninstalls then re-installs the module with the `-y` option indicating answer yes to everything (obviously that is a development tool rather than a run on production site thing).

Hi! We, as an Drupal development agency love your writing and drush itself :) Great tool with huge posibilities.

I always use this command: drush archive-dump

I never use drush, for the simple reason that I am not able to get it installed. I work on Windows and a localhost. Istalled Composer global. I used the command composer global require drush/drush. It's installing. But no drush commands work and often after reinstalling drush errors apear. it's a pitty.

Did you add Composer's directory to Windows' PATH environment variable?

If you installed Composer globally, then the directory you need to add to PATH is something like this:

PHP also needs to be in your PATH.

The PHP and Composer parts of my PATH variable are like this:

C:\Users\Jordan Bradford\AppData\Roaming\Composer\vendor\bin

I have multiple versions of PHP on my machine, so my PATH variable tells Windows the specific version I'd like it to default to using (7.0.8) and the C:\php part takes care of exposing the rest of the versions I have.

Favorites for fixing problems - rr, uli. Always wanted to use runserver more but never got round to trying it out.

Thanks for the info about the watchdog-show and the --tail parameter. I will definitely use that soon. :)

I'm a big fan of the drush uli command that has already been mentioned. Also, before using drush up, I always use drush ups. It works similar to the drush pm-update --pipe command, but gives you a bit more information. That way, you can inspect the pending updates before deploying them.

Another command I like is the drush ups --lock=modulname --lock-message=“reason“ command. It locks modules, so they are excluded from the next drush pm-update. Comes in very handy when you have modules that you know will make problems when getting updated, and don't want to accidentally update them sometime later.

I also wrote a little beginners guide for drush myself, which I also use too look up stuff myself when I forget them. :) It's written in German however...

Good list, thanks!!!

my site is (is not multisite), where drupal 7 installation is in the subfolder 'drupal7'.
How can i update the modules (core and contrib) in domain/drupal7/modules and domain/drupal7/sites/all/modules with drush?


Blair Wadman's picture

Yes, as long as you are somewhere in the drupal7 subfolder when you run your Drush commands, or you have an alias.

New comments for this tutorial have been turned off.