Multisite Aliasing in Drupal 6

Prerequisites: multisite, patching

If you, like us at Tarakan Design, make frequent use of Drupal Multisite and your workflow involves various incarnations of development, staging and production sites, there is good news from Drupal.org.

One of the problems we face in the development of sites using this three-legged workflow lies in database migration as we move from phase to phase. Typically, the sites/ directory on a development server will contain a directory like sites/newsite-development.localserver.com. Similarly, the staging server might contain sites/newsite-staging.stagingdomain.com and finally the production site with sites/newsite.com. The problem is that when we migrate the database between any two of those installations, it contains references to the wrong site URL. Yes, it is true that well-behaved core and contributed modules only store paths relative to the site root, but what about files in the sites/newsite-staging.stagingdomain.com/files directory? Those paths are relative to the site root yet are still dependent upon the site URL.

Fortunately, there is an available patch for Drupal 6 that fixes this particular issue. This patch makes a minor alteration to bootstrap.inc that looks for a file called sites.php in the sites/ directory. The sites.php file allows you to specify site aliases that uncouple real site URLs from site URLs referenced by the multisite mechanism. For instance, in the above example, sites.php would contain: 

$sites = array(
  'newsite-development.localserver.com' => 'newsite.com',
  'newsite-staging.stagingdomain.com' => 'newsite.com',
);

Now, when you point your browser at http://newsite-development.localserver.com, Drupal will use the 'newsite.com' multisite directory even though you are on your development server. For instance, you can specify "sites/newsite.com/files" in the File System settings (admin/settings/file-system) and you will still be correctly configured across your development, staging and production installations.

Of course, you are still hosed if somebody puts a fully qualified path on your site (say, in your main site navigation menu), but we'll just call that a "personnel" issue.