I spent a great of yesterday morning re-organizing the directory structure on my webhost, where this site along with my client’s ones are stored.
The fact is I am moving toward a Drupal multi-site installation, that is a single set of core files serving multiple sites at the same time. Currently I am running three sites (including this one) with a shared code base, but I am planning to start integrating some more very soon. The fact is with a single code base to maintain, things are simpler to manage (because everything is under the same directory) and upgrade (in case of a patch-release you need to upgrade only one code base).

the brave decision

Soon after I begun this task, I realized I’d have to change the files directory location, because otherwise sites were saving uploaded files in the same directory. In the Drupal administration page there is a warning about this action: “Changing this location after the site has been in use will cause problems so only change this setting on an existing site if you know what you are doing.”
I needed to get this done anyway, so I assumed I knew what I was doing.

one error to doom them all

One site had more than 200 files uploaded through Drupal, so I had to be careful about what I was doing. Manually re-inserting all those images would have killed me and my social life for a couple of days if not more. So I put the site on maintainance mode, notified all editors to keep away from the site for a while and started hacking my way through the changes. I changed the “files/” directory location setting to “sites/SITEDOMAIN/files” and went around checking if everything was displaying correctly (not true for any defintion of “Everything”: I actuall grepped my httpd logs for “files/” string, so I knew where and what to check after change). The site uses imagecache module for image rescaling and resizing and I expected it to be the biggest source of headaches. But instead it turned out all imagecached images were being correctly linked to the new file location.

the case for some elite SQL trickery

Instead I had some minor problems with CCK file fields. They present a strange behaviour which I still have to determine whether it is a bug or a feature. The image will display correctly regardless that the saved filepath in the files table is relative to the Drupal root or to the “files/” direcory location setting. Anyway in my case the files were stored with full path from Drupal root, so the old “files” location was embedded in the table. I just ran this query to fix things up:
UPDATE `files` SET `filepath` = REPLACE(`filepath`, "files/", "sites/SITEDOMAIN/files/");

who greps last greps better

I then rapidly scanned the site checking logs for 404 errors while visiting the sample pages I selected during the first steps grepping the logs. Everything seemed to work flawlessly. I then put the site back online and notified editors. I am now waiting to see if any of them reports problems of any kind. Anyway I am pretty satisfied, it hasn’t been the nightmare I expected it to be. Now I have a clean and rational installation, with all files, modules and themes under the sites/ directory, which sits out of the Drupal installation directory and is simply linked in the Drupal root.

Technorati Tags: change configuration Drupal files location setting hack multi-site tips trick