Multisite and dynamic configuration items in Drupal : help from Apache

Having recently merged a number of separately configured sites into a single consolidated multisite, I found myself with URLs like:

http://www.site1.com/sites/www.site1.com/files/somefile.png

...on all except the main site of the multisite configuration.

Although img_relocator allows me to just type things like:

<img src="somefile.png" />

... and still have these URLs be automagically generated, they still appear to those users who actually look at the URLs.

Enter mod_rewrite

Abandon all hope, ye who enter here

With these sites running over Apache 2.x, mod_rewrite offers a simple way to rewrite the files URLs: in the Apache site definition file for the vhost describing the site, we can use:

And all of a sudden, the image links look

All of this is nice and well. Or is it ?

system.module and color.module

Actually, not everything works so well: both system.module and color.module generate directories and files on the fly, respectively files/css/someuniqueid and files/color/someotherid, and place them in the designated files directory for the sub-site.

But since we have overriden the actual sub-site placement of the files directory to make it appear under the root of the virtual host instead of where it actually is (that is to say, the files directory in the config for the sub-site is actually set to files instead of sites/www.site1.com/files, both of these modules generate their files in the files directory of the main site, which is only logical.

At this point, you'd probably want to return to the default files setting, or tweak the modules to force them to resolve the files directory relative to the path of the sub-site directory, but this is not necessary: all it takes is one additional rule, telling Apache not to rewrite these URLs:

Notice the additional RewriteCond ? This is how we tell Apache not to apply the RewriteRule if the path matches files/color or files/css. We needn't anchor to the start of the string since this line is only activated if the first line already matched, and that one is itself anchored.

Debugging mod_rewrite behaviour

Here be dragons

Now, not having worked a lot with mod_rewrite (I only touched the main Apache code itself years ago), I often find it is difficult at best to be exactly sure of the way the server processed the rewriting rules. Tweaking LogLevel, even to debug will only show the most obvious misses, like infinite loops in redirections, but not tell you anything about why they occurred. Or why an anchored search fails, for instance.

Luckily, Apache offers the RewriteLog parameter, even in Apache 1.x, and this one is a boon, but needs to be handled carefully, because raising the RewriteLogLevel will produce incredible volumes of debug info, slowing your server to a crawl. The lines to use being as such:

RewriteLog "/var/log/apache2/rewrite_log"
RewriteLogLevel 9

... I found it useful to use two small shell scripts:

a2enlog

#!/bin/sh
CONFIG=/etc/apache2/sites-available/$1

sed s/#RewriteLog/RewriteLog/ < $CONFIG > "$CONFIG".new
mv $CONFIG "$CONFIG".old
mv "$CONFIG".new $CONFIG

a2dislog

#!/bin/sh
CONFIG=/etc/apache2/sites-available/$1

sed s/RewriteLog/#RewriteLog/ < $CONFIG > "$CONFIG".new
mv $CONFIG "$CONFIG".old
mv "$CONFIG".new $CONFIG

Using the log

Now, considering the volume of data output to this log, it is typically best to use these two files along with a single query, that way:

a2enlog site1 ; apache2ctl restart ; wget http://www.site1.com/some/url ; a2dislog site ; apache2ctl restart

Unless the site is heavily loaded, in which case you probably shouldn't be messing with it while it is live, this will result is only your single request being logged, making things really understandable, especially if you cut the log vertically to remove the request separation info, which in this case is just noise. A simple instruction like 1G!Gcut -c76-500 in vi does it wonderfully, provided you adjust the first column number depending on your site name.