Full Service Web Design Agency

When putting a lot of work into a Drupal site, it’s nice to add some minor touches to give the project a more professional feel. In some ways, you are selling the quality of your customizations to the client, you boss, and other developers.

Module .info

The first example is for the Modules page. When I visit this page I like the custom modules to be clearly displayed in a package above the other modules, which gives them a quality of importance. To achieve this we exploit the fact that Drupal will sort the modules page by package, forcing a space at the start of the package name. Here is the .info file:


name = emspace.com.au Code
description = General code for functioning of emspace.com.au
package = " Em Space"
core = 6.x

Theme .info

The same goes for theme. This is especially true for a codebase that has a lot of contrib themes on hand.


name = " Em Space Orange"
description = Administration theme
core = 6.x
engine = phptemplate
base theme = emspace2010
...

Going further…

It is also possible to add HTML to the “name”, “package” and other .info values. So if you really want, you can jazz up your module listing with a marquee tag, or an icon in place of the “version” number.

This article demonstrates Drush aliases and the configuration you need to pull the database and files from one Drupal site to another with the following commands:


# Syncronize sites/emspace.com.au/files from production to dev.
drush rsync @prod:%files @dev:%files

# Syncronize database (minus ‘custom’ tables) from production to dev
drush sql-sync –structure-tables-key=custom –no-cache @prod @dev

Background

I spoke with Moshe at Drupalcon SF about some new tricks in Drush. I realised that my bespoke deployment scripts would soon be obsolete. Today I figured out what I needed from Drush and this article describes my new preferred “one-liners”.

Along with Moshe et all, I want to specifically thank Greg Anderson. Judging by his answer to my issue here, he’s put a lot of work into this part of Drush, and I think we’ve only scratched the surface of what is possible.

Set-up

You need two working Drupal sites for this example – preferably on the same server (to begin with). I created two sites on my localhost. This simply makes debugging easier while you get the hang of aliases.

My setup, in case it helps:

• Mac OSX
• MAMP PRO 1.9 (Normal MAMP would be OK, but harder to configure custom hostnames)
• Drupal 6
• Drush 3.1 lives in /Library/PHP/drush
• “Production site” is set up as http://prod.local and lives at /Users/sime/Sites/prod.local
• “Development site” is set up as http://dev.local and lives at /Users/sime/Sites/dev.local

I have /usr/bin/php soft-linked to the MAMP php 5.2 executable. In MAMP I’ve edited the php.ini template for 5.2, increasing the memory limit to 128mb. I have Drush aliased simply as alias drush="php /Library/PHP/drush/drush.php" in my .bash_profile.

Set up your aliases

For these examples you only need one configuration file on your local machine. Even if you’re working with a remote production server, the configuration still lives on your own machine.

Open the terminal, or bash window. Create a directory called .drush in your home directory, if it doesn’t exist already. Add the drush aliases file here.

mkdir ~/.drush
touch ~/.drush/aliases.drushrc.php

(~/.drush/ is one of the places where Drush will look for configuration files. There are other configuration files that can live here.)

Start with a very simple example using the dev site only. Note, a syntax error in this file will kill drush with the error “Drush command could not be completed.”.


<?php
$aliases['dev'] = array(
'uri' => 'dev.local',
'root' => '/Users/sime/Sites/dev.local', // This doesn't work with ~/Sites/dev.local
'path-aliases' => array(
'%files' => 'sites/emspace.com.au/files',
'%dump' => '/Users/sime/tmp/drush/sql-sync-dev-local.sql', // Arbitrary location for temp files
),
?>

Some alias-enhanced Drush commands

Let’s run a few commands to verify that the aliases are working correctly and to get the hang of things.

See the status of the site. This should print a dozen+ rows of information:

drush @dev status

Print where the files directory is

drush dd @dev:%files

Switch to the files directory (note the backticks to express the output as part of the command):

cd `drush dd @dev:%files`

Dump the database, and then load the same database. Keep these handy especially when you’re experimenting.

drush @dev sql-dump > `drush dd @dev:%dump`
`drush @dev sql-connect` < `drush dd @dev:%dump`

Final aliases.drushrc.php


<?php

$aliases[‘dev’] = array(
‘uri’ => ‘dev.local’,
‘root’ => ‘/Users/sime/Sites/dev.local’,
‘path-aliases’ => array(
‘%files’ => ‘sites/emspace.com.au/files’,
‘%dump’ => ‘/Users/sime/tmp/drush/sql-sync-dev-local.sql’,
),
‘command-specific’ => array (
‘sql-sync’ => array (
‘simulate’ => ‘0’,
‘structure-tables’ => array(
‘custom’ => array(‘cache’, ‘cache_filter’, ‘cache_menu’, ‘cache_page’, ‘history’, ‘sessions’, ‘watchdog’),
),
),
‘rsync’ => array (
‘simulate’ => ‘0’,
‘mode’ => ‘rlptDz’,
),
),
);

$aliases[‘prod’] = array(
‘uri’ => ‘prod.local’,
‘root’ => ‘/Users/sime/Sites/prod.local’,
‘path-aliases’ => array(
‘%files’ => ‘sites/emspace.com.au/files’,
‘%dump’ => ‘/Users/sime/tmp/drush/sql-sync-prod-local.sql’,
),
‘command-specific’ => array (
‘sql-sync’ => array (
‘simulate’ => ‘1’,
),
‘rsync’ => array (
‘simulate’ => ‘1’,
‘ssh-options’ => ‘-p9999’,
),
),
);
?>

The command options

Apart from adding the Production alias, the full configuration adds additional keys.command-specific

This defines a list of Drush commands for which we want to define options. Both “prod” and “dev” site aliases define options for “sql-sync” and “rsync” which are the two Drush commands we will need.

simulate

This allows us to set the Drush option “simulate”, which will dry-run the command. It’s the equivalent of:

drush --simulate=1 command

Simulation isn’t just a party trick here. Setting simulation for the Production site means that we cannot accidentally overwrite the Production data or files.

structure-tables

Allows us to define a set of tables for which we never want to pull down the data. It can significantly improve download speeds to avoid the data overhead of the cache/search/session/watchdog tables.

Each set of tables has a key, in this example the key is “custom”. This can be specified in the drush command like this:

drush sql-sync --structure-tables-key=custom @site1 @site2

mode and ssh-options

These two options are relevant to the drush rsync command. Mode is for setting unary options: a mode of “avz” will result in “rsync -avz”.

SSH Options allows additional options to the ssh component of the command. In my case I have a few servers with ssh on a non-standard port – not common, but is a good example. “rlptDz” is my preferred – it is the same as Drush’s default (“az”) except it doesn’t try to sync Groups and Users.

The commands

With the aliases.drushrc.php in place, the commands we need are as follows.

# Syncronize sites/emspace.com.au/files from production to dev.
drush rsync @prod:%files @dev:%files

# Syncronize database (minus ‘custom’ tables) from production to dev
drush sql-sync –structure-tables-key=custom –no-cache @prod @dev

Final notes

Soon you’ll want “Production” to point to a real live website. The remote server will need to have Drush available, but it doesn’t necessarily need any more than this. You simply need to add some extra options in your aliases.drushrc.php.

There is another strategy for protecting the live site. Read the example policy.drush.inc for more. My understanding is that this will allow us to set a universal policy for different sites in the deployment chain. In practice sometimes I want to push data to the live site, so my preference was to go with aliases which can be overridden in the drush command.

This post demonstrates some Drush @sites usage, but perhaps better shows where the Drush @sites feature is at.

Tonight on a multisite installation, I wanted to run a query against every database. I had a play with Drush 3 HEAD, and found that I could get what I needed quite easily, and in a way that I will probably re-use.

Quick @sites example with variable-get

Say that you want to know the value of a particular variable on all of your sites. The first stop is to try the “variable-get” command.

# Navigate to the multisite’s root (or use the -r option)
drush @sites variable-get preprocess_css

The output is pretty clear, except you can’t identify the site that each variable is associated with.

preprocess_css: “1”

preprocess_css: “0”

preprocess_css: “1”

preprocess_css: “1”

…

I expect the smart guys working on Drush will fine-tune this over time because clean output will be required for other scripting goodness. But in my case this is not a problem and is easily worked around.

Execute a query

My solution was to construct a query that shows me the value of preprocess_css plus the site name. This is done by joining the variable table on itself with no ON clause. Then the WHERE clause removes rows we don’t want.

This looks a bit tricksy, but remember it’s just drush @sites sqlq "MY QUERY". The back slashes wrap the command over multiple lines so you could paste this into your bash prompt as is.


#The command is long, use a backslash to separate the command over a few lines.
drush @sites sqlq "SELECT v1.value AS site, v2.value AS val \
FROM {variable} v1, {variable} v2 \
WHERE v1.name = 'site_name' AND v2.name = 'preprocess_css'"

This does the job. I can now see which sites have CSS preprocessing turned off.

site val
s:11:”Hobbs.id.au”; s:1:”1″;

site val
s:9:”Eu no Rio”; s:1:”0″;

site val
s:28:”Patterson Lakes Netball Club”; s:1:”1″;

…

Another query example

Just another example of that query. In this example let’s find all the user/1 email addresses. I’ve done it here in raw SQL with explicit syntax.

SELECT v.value AS site, u.mail AS admin_mail
FROM users AS u
JOIN variable AS v
WHERE u.uid = 1
AND v.name = ‘site_name’

Putting that onto a drush command (remember to add {} around your table names if applicable!) you get something like:

site admin_mail
s:18:”Example Site”; [email protected]

site admin_mail
s:21:”Foo Site”; [email protected]

site admin_mail
s:15:”Bar Site”; [email protected]

Wrapping up

None of this I would consider best practice, but hopefully gives you an insight into how amazing and stable these tools are becoming! Good luck drushing.