[module] Drush [command line admin and scripting]


Project page quote (external)
Project page quoted on: 

The Drush project has moved to Github.

Drush is a command-line shell and scripting interface for Drupal, a veritable Swiss Army knife designed to make life easier for those who spend their working hours hacking away at the command prompt.

Drush is mostly intended for use on dedicated servers or virtual private server partitions (VPS):

If you are going to get serious about Drupal you are going to have to get to know at least some Drush commands. If you want to work professionally as a Drupal developer or consultant for a Digital Media Agency or Web Development Agency, and with multi-staged development, then you will absolutely, definitely, have to be at least familiar with most major Drush commands and its capabilities.

It's not a lot of use for sites running on shared web hosting accounts that don't offer Secure Shell (SSH) access. However, even then, you can learn how to use Drush on your local development machine if you have a local version of a site that you develop before you upload it to a shared web server.

To get a feel for what Drush can for you via command line, please visit Drush.org. Much, but not all, of the functionality of Drush can be achieved anyway through the regular core admin user interface and through the actions offered by the wonderful Devel, but Drush enthusiasts insist the command-line approach it is usually faster.

There is no doubt that one can install a new site with Drush very quickly, there it shines.

It can be useful for working with Drupal installations on a localhost (such as a development version of a site), for preparing sites for move to production hosting, and for migrating sites from one host to another, and for larger projects it can be scripted to automate spawning whole sites etc.

While I understand the need for it, and it is sometimes a massive time saver, I am not as big a fan of it as some colleagues, and I still do a lot using the regular Drupal admin GUI and other UNIX tools. I've found there are too many exceptional cases where I have to do things using an SQL client like say PhpMyAdmin and plain ol' file uploading and UNIX file manipulation in combination with regular Drupal admin through the browser admin UI.

For example, although drush module update does backups of previous versions of modules, you have to take care with patched/hacked versions to make clearly indicated copies first anyway to areas outside the Drupal backup system:

As for the database table manipulation commands, I would rather mostly simply do it in a good SQL client. It can however be useful if one has to migrate a large number of users, a task one can perform with Drush scripting that I have previously performed with custom PHP scripting.

I do quite like these 2 backup and restore commands:

archive-dump: Backup your code, files, and database into a single file.
archive-restore: Expand a site archive into a Drupal web site.

But whether they work depends a lot on your system setup.

WARNING: fluency with Drush is often expected at Drupal job interviews

Although it's not rocket science to anybody who has used UNIX, "intimate" knowledge of Drush seems to be a very common Drupal job requirement; so become familiar with it (see some of the tutorial links below, install it and experiment with it), and when they ask at the job interview "Do you know Drush ?" simply answer "Yes, of course". Learning to use Drush would take any experienced IT person a few hours or a day; It's hardly a deal-breaker for engaging an otherwise good Drupal developer.

On installing with PEAR

The instructions at Drush's PEAR Channel Server are not entirely clear:

Registering the channel:
pear channel-discover pear.drush.org

Listing available packages:

pear remote-list -c drush

Installing a package:

pear install drush/package_name

Installing a specific version/stability:

pear install drush/package_name-1.0.0
pear install drush/package_name-beta

The thing is that after performing the listing of available packages all you will see is something like:

# pear remote-list -c drush
Channel drush Available packages:
Package Version

There is (at least as of 25 Feb 2014) only one "package". To install it simply use:

# pear install drush/drush-

On module installation with Drush

The following is adapted from the excellent Beginner's Guide to Drush, the Drupal Shell:

'Let's install Views (I'm sure you know about this module). To do this, you first have to run the following command:
drush pm-download views


drush dl views

Either one of these commands will download Views and place it in the appropriate sites/all/modules folder.'

But the fact is, that when I am working with remote production sites and making changes live, I don't like installing straight into sites/all/modules ! I work on Mac OS X, and I like to use the Mac file label colouring system to indicate my workflow on downloaded modules/projects, and I like to even use the Mac spotlight comments metadata to keep notes on issues and concerns etc. I can't do that with Drush if it has simply installed the entire thing onto a site already (unless the remote server is by some miracle a Mac with Finder access). I also like to be able to duplicate troublesome .module and .inc/.php files on my Mac staging area and take records on them (using say renaming and/or spotlight metadata) before patching them or hacking them, and I certainly can't do that with Drush.

The dependencies resolution aspect during module installation is no doubt very nice:

'Now that Views is installed, enable it with the following command (the long version of which being pm-enable):
drush en views

You'll see that Drush immediately tells you that Views requires Ctools to be downloaded and enabled and asks you if it should perform those actions as well. If you select yes, it will download Ctools and will ask you once more to confirm whether you want Views and Ctools to be enabled. Say yes again and it's done. Now, how many clicks and URL copies have you saved with just this one command?'

This is also a nice feature:

And if you want to have an overview of all the projects on the site, you can run the following command (the long version of which being pm-list):
drush pml

Reloading the module list page using the admin UI command on a Drupal site can take some time, the above is quick.

But at the end of the day, there are simply too many things I can't do with Drush, too many exceptional circumstances, and I don't find myself using it as often as most Drush enthusiasts, not least because some of the production sites I work on for clients are on shared web hosting servers that don't even support command line access.
Visit also