Drupal Staging - Site Update

In researching more streamlined options for our Aegir based dev/live cycle, I (re)discovered several takes on the staging problem: everything in code methodology, the deploy module, the site_update module, migraine, the patterns module and of course features.

Each seems interesting in its own right, so I have decided to do some testing to see if one or more can help us better our current staging procedure. I will start with the "site update" module, since it seems to offer a light yet efficient take on sharing settings between sites. It might also be easily integrated in our current Aegir based workstream.

So I got to work. Following the spirit of the README.txt I created three new sites in Aegir, a DEV, LIVE and BASE install. Drush downloaded some essential modules (views, cck, rules), of course including site_update-6.x-1.x-dev. Added a test content type, a test view & changed some permissions on the base install. Then enabled the module on all three sites, necessitating the install of the "bad judgement" module(!).

Following the base site configuration I tried to run the database dump script from the sites/basesite/ directory. That didn't work out of the box on our Aegir server, since the database dump script retrieves its database settings from settings.php, which in an Aegir based site is to be found in drushrc.php.

Luckily, all that was needed for Aegir compatibility were some small changes to the site_update_dump script:


$parse_error = false;

// RvE 03-03-2011 added drushrc $options

if (isset ($db_url) && preg_match('/^mysqli?:\/\/(.*):(.*)@(.*)\/(.*)$/',$db_url,$matches)) {

  $db_conf->username = $matches[1];
  $db_conf->password = $matches[2];
  $db_conf->hostname = $matches[3];
  $db_conf->database = $matches[4];

} else if ( isset($options) && $options['db_type']='mysqli' ) {

  $db_conf->password = $options['db_passwd'];
  $db_conf->database = $options['db_name'];
  $db_conf->username = $options['db_user'];
  $db_conf->hostname = $options['db_host'];

} else {
  $parse_error = true;

if (!$parse_error) {


// RvE 03-03-2011 added -h option

function build_mysqldump_command($db_conf, $options, $ignore_tables, $include_tables) {
  $command = "mysqldump -u $db_conf->username -p$db_conf->password -h$db_conf->hostname  $options";


Now you are able to generate sites/basesite/database/site_update.sql by running site_update_dump from the base site root and copy the resulting site_update.sql to the previously created sites/devsite/database and sites/livesite/database directories.

Before running an update, there is one additional step specific to multi-site installs. Site_update by default looks for the SQL file in sites/all/database. In the case of a multi-site install you have to tell every site where its particular site_update.sql resides. Normally you set this path in settings.php. Within an Aegir controlled environment, you have to add the path to a local.settings.php file (since Aegir is allowed to override settings.php).

//put the following in the sites settings.php or local.settings.php
$conf['site_update_sql_file'] = 'sites/devsite/database/site_update.sql';

Run update.php and all base data is indeed nicely added to the dev and live sites. Still, I had hoped the module might offer me a little more by default. For example creation of content type tables when adding new CCK types. For now I'll keep this module in mind. Next module to be tested: deploy.

// added 06-03-2010:
made a patch available at http://drupal.org/node/1081230#comment-4175934


kirill's picture

It's informative, but rsync +

It's informative, but rsync + migraine better solution...