My top 10 Drush commands

Learn more

Master Drupal Development: Get the book to scale the learning curve faster

Start learning Drupal 8 development today: Get the free 7 lesson course

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.

Get your free Drush Cheatsheet

Drush is awesome - and every awesome thing requires a cheatsheet!

Get your Drush cheatsheet


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.

Add new comment