Drush is an incredibly powerful tool for working with Drupal sites, and if you're not using it to your full advantage, you're almost certainly missing out. However, Drush has so much functionality that may not be immediately apparent that it's likely that we're all missing out on ways it could help our workflow.
Drush can run on a site even when it's not your working directory through the use of Drush aliases. That alone could speed up work on local sites, but you can use multiple aliases for the same site including details for connecting to remote environments over SSH!
Let's get set up.
Aliases are defined using a simple config file. In ~/.drushrc/ you can create a file with a name of this pattern:
... where <sitename> is your site alias name. That's whatever you want to refer to the site by. Inside this file, you'll want this as a base:
<?php // <sitename>.aliases.drushrc.php $aliases['local'] = array( 'site' => <sitename>, 'uri' => <local uri>, 'root' => '<full local path>', ); $aliases['<alias name>'] = array( 'site' => '<sitename>', 'uri' => '<remote uri>', 'root' => '<full remote path>', 'remote-host' => '<SSH ip or hostname>', 'remote-user' => '<SSH user>', );
Keep this consistent with the site name you used in the filename. This is used as the main name of the alias.
The local URI of your development environment, with protocol ignored. If your site is set up locally as 'http://example', this will be 'example'. If it's 'http://example.local', then 'example.local' is what you should use.
full local path
The local path to the site root, in the filesystem. For example, '/home/user/sites/sitename', or '/var/www/sitename/htdocs'
full remote path
The path to the remote site root, in the filesystem of the remote server. For example, '/var/www/sitename/htdocs' or '/srv/www/sitename'
SSH ip or hostname
The IP or hostname you use to connect over SSH to the remote server. For example, '198.51.100.0' or 'example.com'
The remote SSH user.
If you're authenticating using a password, use this line:
'ssh-options' => '-o PasswordAuthentication=yes',
Though, of course, you should look into authenticating with public and private keys. It's way more secure and it's actually more convenient.
Using your aliases.
Now, you can run any Drush command using an alias! You can refer to your alias by prefixing its name with @. Try it:
drush @<sitename>.<aliasname> status
The dot is used to separate the site name you used and the individual alias names. So, to enable a module on your dev server, you'd run something like:
drush @example.dev en module_name
Some commands take aliases as arguments, like sql-sync (we'll get to that in a moment).
Synchronising your environments
Administering sites this way is really convenient, but there's a catch. You could well be interfacing with a remote server running a different version of Drush, and they don't play nicely together.
Here's a great guide to setting up multiple versions of Drush on Ubuntu. The process for installing versions into somewhere like /opt using Composer will apply to any platform. However, instead of using require-alternatives or an equlivalent, I prefer using command line aliases like 'drush6' pointing to my Drush 6 install.
To do that, add lines like this to your ~/.bashrc (or equivalent, if running something like zsh or the environment is different):
Actually using your aliases
Here are some incredibly useful commands that you can use aliases with.
drush sql-sync @alias1 @alias2
One of the most useful commands ever! Dump and download the database from alias1 and overwrite the database of alias2 with it - a database sync in one command.
This is a normal drush command, but we can use it remotely. sql-sync can be fickle, so as a fallback you might want to dump the remote database to a file. A command like:
drush @alias sql-dump > /tmp/dump
will download the database to its own file, which you can then import...
drush sql-cli < /tmp/dump
to your current site. Or another alias.
You might want to use drush sql-sanitize to remove real email addresses and passwords in a database you fetched in this way.
Note: this is relying on standard output to dump the database, and that output can get polluted a bit by drush or the ssh process. You might have to open up the dump file and remove a warning line from the top before you can import it.
drush rsync @alias:<path> <local path>
Use the power of rsync to synchronise your files directory. If you don't use a solution like Stage File Proxy to have your files appearing locally, you probably have to copy these around often. So let drush do it for you. To just get the files, use a command like this from your root directory:
drush rsync @alias:sites/default/files sites/default/files
And remember that all the usual Drush commands and tricks can work this way. Need to reset the flood table? You can do that without going into your database management tool, and with an alias, without even connecting via SSH yourself.