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).
h3. 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.
h3. 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.
h3. 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/");
h3. 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.
Comments
Anonymous (not verified)
Sat, 06/09/2008 - 16:41
Permalink
Ran into a similar problem
Anonymous (not verified)
Mon, 13/10/2008 - 18:33
Permalink
Thanks for your overview
That’s a point.
I (and others on that thread) confirm the same behavior (not saving the images path and giving a false message) for the image module alone, and the fix is analogous:
Go into the database and change the path to what the image module is refusing to save. (image_default_path, not the user picture path from Nancy’s example.)
Then everything works.
So the image module (maybe also the user module unless its relying on the image module for user picture paths) is providing a false failure— saying a path does not exist and cannot be saved when it does exist.
I do not know what triggers this bug, but as a starting point we’re using a multisite install with “sites/example.com/files” as the files path for a given site, and an “images” directory inside that.
Anonymous (not verified)
Mon, 16/03/2009 - 18:32
Permalink
Thanx a ton for posting this.
Anonymous (not verified)
Tue, 21/04/2009 - 21:47
Permalink
Thanks! This helped me a
Anonymous (not verified)
Wed, 06/05/2009 - 19:33
Permalink
Tried but didn't work
Anonymous (not verified)
Tue, 16/06/2009 - 11:19
Permalink
About #1
Anonymous (not verified)
Thu, 12/11/2009 - 22:09
Permalink
Thanx a ton for posting
Anonymous (not verified)
Sat, 19/12/2009 - 07:00
Permalink
Where is the file Path Stored
Anonymous (not verified)
Sun, 03/01/2010 - 13:11
Permalink
Great tip! This SQL
Anonymous (not verified)
Tue, 16/03/2010 - 10:48
Permalink
Webform
Anonymous (not verified)
Sat, 30/10/2010 - 04:52
Permalink
Awesome, thanks!
Anonymous (not verified)
Wed, 23/02/2011 - 10:19
Permalink
Drupal always being one of