Lori's blog

We have been using Drupal multisite to host a number of websites that are mostly used for developing and reviewing sites with customers. Although simply understanding how to setup your first Drupal multisite websites is tough enough it starts to get interesting when dealing with custom themes and php code (running within blocks, for example).

The simple multisite setup we use has worked well for us but I expect there are aspects to it that could be improved and, certainly, there are tradeoffs we make in terms of portability. However, there are probably some of you could benefit from our experience.

Lori and I are neither experts in php nor have we done any development of Drupal modules. Lori is a recovering corporate programmer turned designer and has become pretty good at creating phptemplate-based themes. I am a Unix hack from long ago and have found ways to leverage our VPS Linux-based hosting (and those of our larger customers) to create a Drupal multisite configuration that is easier to understand and (somewhat) portable.

Primary Problem: Changing URL Paths

The primary problems we have run into with Drupal multisite configurations is the url path referencing files. These can be paths to images, style sheets, audio files, PDF files, or just about any type of file content that needs to be referenced from templates or from within Drupal nodes or blocks. The challenge is keeping these references simple (meaning, no php code) and portable (at least portable between the development and production hosts).

In a Drupal multisite setup files specific to a particular site are stored in a directory under "/sites". So, the file map.pdf used within www.example.com hosted in a Drupal multisite configuration would be stored in the sites directory referenced by http://www.example.com/sites/www.example.com/files/map.pdf. So, imagine developing this site on a development server with a different url (meaning a different path to map.pdf) and then moving this over to a production server. This is just one url reference changing. Imagine a dozen or more that change.

Hosting assumptions: Linux VPS and No Sub-sites

We host our development and production Drupal sites on a virtual private server running Linux. This allows us to make liberal use of symbolic links and Apache virtual hosts. We also create a DNS host name for each site we are developing. In the eample below we are using the hostname customer.4ldesigns.com.

We also try to avoid the use of "sub-sites", where a single DNS hostname has multiple Drupal sites distinguished by directory paths in the url. For example, www.example.com/subsite_a and www.example.com/subsite_b.

So we really didn't come up with a better idea for Drupal multisites. We just simplified our needs enough to fully take advantage of symlinks.

All of our virtual hosts are in a single directory tree. In this example, we'll call this /var/www/vhosts.

Let's work through this directory tree one level at a time.

/var/www/vhosts

• Has two files, both directories: customer.4ldesigns.com and drupal_5.

/var/www/vhosts/drupal_5

• Has two files, both directories: sites and drupal-5.2

/var/www/vhosts/drupal_5/sites

• Has two files, one directory and one symlink.
• c1 is the standard drupal multisite directory containing settings.php and the directories themes, modules, and files.
• customer.4ldesigns.com is symlinked to c1.

/var/www/vhosts/drupal_5

• Has two files, both directories.
• drupal-5.2 is the standard Drupal distribution with one change; the sites directory is symlinked to /var/www/vhosts/drupal_5/sites.
• There are two advantages to pulling sites out of the standard Drupal directory tree. First, directory paths on remote workstations used for developing themes don't have to change whenever there is a new release of software. Lori uses Dreamweaver and we only need to define a site once using /var/www/vhosts/drupal_5/sites.
  
  Second, it is much easier to only provide read/write access to the sites directory. It is tempting to make a "small" tweak to a core file. Not providing write access outside of the sites directory removes this temptation and keeping it in a separate directory means we can make this change just once and not with every software upgrade.

/var/www/vhosts/customer.4ldesigns.com

• Has two files, one directory and one symlink
• htdocs is a symlink to /var/www/vhosts/drupal_5/drupal-5.2. This may be a personal choice since we could have configured the Apache DocumentRoot to /var/www/vhosts/drupal_5/drupal-5.2 directly. I simply prefer the symlink approach because changing the Apache configuration files requires elevated privileges.
• The logs directory contains site-specific Apache access and error log files.

The main advantage of using symlinks within the Drupal sites directory are references to site-specific content can use the path http://customer.4ldesigns.com/sites/c1/...". Since our production site also uses Linux hosting with the capability of creating symlinks these paths do not change. The target production system, for example, might be http://www.customersystem.com. In this case we simply create a new directory in the sites directory (called www.customersystem.com) and symlink it to c1. Drupal will find the correct settings.php (via the www.customersystem.com directory) and url references will find the content under c1 since it is in the scope of the Apache virtual host's DocumentRoot.

Of course to make this work the Apache configuration must allow the use of symlinks (use Options +FollowSymLinks in the appropriate places).

I hope you found this useful.