Educating Drush
Drupal has great support for multi site installations and so does Drush. All of our sites are deployed through a dev/test/live process so our sites directory always has three sites entries.
This is great, but Drush can't tell which site you're working on so you have to use the --uri argument. Fine, but that can be at best frustrating and at worst dangerous, if you work on the wrong server by mistake.
If your vhosts are well structured then you probably have a directory pattern something like this:
vhosts
-- dev.example.com
-- test.example.com
-- example.com
Using a structure like this we are able to create a drushrc.php file that can automatically set the --uri argument for us, dependent on the directory path that we are in. Note that this can even work if you have a single multi site installation, just set your vhosts up with a bunch of symlinks to your Drupal install.
// from /var/www/vhosts/domain.com the uri argument is domain.com
// allowing for proper drush execution in a multi-site enviroment.
if (preg_match('#vhosts/([^/]*)#', getenv('PWD'), $matches)) {
$options['uri'] = $matches[1];
}
// Also check for local Acquia dev desktop paths.
elseif (preg_match('#Sites/([^/]*)#', getenv('PWD'), $matches)) {
$options['uri'] = $matches[1];
}
So, now you have a drushrc.php file there are some other interesting things that you can do with it...
Block module updates
Sometimes you might have patched modules that you want to prevent from being updated. No problem:
Module locations
It's good to separate custom and contrib modules, and if you use Features it's good to keep those separate as well.
These two lines of code will ensure that module downloads are placed in a 'contrib' folder and that new features are created in a 'features' folder. You will have to create the 'custom' folder youself when you write the modules.
$command_specific['fe'] = array('destination' => 'sites/all/modules/features');
Drush specific ini settings
We've all been there - "PHP: Fatal Error: Allowed Memory Size Exhausted". It's usually considered pretty bad practice to ramp up the memory limits higher than you need them on your production environment, but it can also be pretty tricky to debug - finding out where all the memory went when you have none left. Drush is interactive, so if it's running out of memory, chances are you know that it's only a temporary thing whilst your running a specific command. Setting the memory limit in drushrc keeps undesirable settings out of settings.php (which might not always be called) and out of htaccess (which is never read for Drush calls)