Drupal: changing "files" directory configuration setting

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

I ran into this same problem recently and with the help of the SQL query in this post was able to update all the file paths in a flash. It saved me quite a bit of time, thanks!

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.

I also ran through same problem an ur solution has helped me. Keep doing the good work.

Thanks! This helped me a ton. Please consider submitting it to the Drupal docs.

I did the above command to update the tables, and it did update them. Viewing the info in MySQL shows they’re there, with the new directory structure. I then even ran update.php but all pages still reference the ‘default’ location in the directory name, they did not pickup the edited / updated mysql tables. What gives? Is there another table that should be updated?

Hi Layoric, i had the same problem and i saw in db that body and teaser already had the old path. So you only have to execute the above query with node_revisions table and body and teaser fields. Hope help you. Ciao

Thanx a ton for posting this. I was having the same type of issues and difficulties with the configuration. exotic car rental los angeles flannel sheets

Hi there, So Drupal stores it’s file path’s in the database? I have recently moved a website from localhost (MAMP) to a webserver. Everything works fine, except the images. They still point to ‘old-directory/sites/default/files’. I’ve seen some threads on D.org about changing the settings.php file but this doesn’t seem to be right in my case. Should I just chop the directory prefixes off all of my image paths in the database or is this too hacky? regards, Brock

Great tip! This SQL statement helped me out.

Your post was really helpful. I spent a lot of time trying to find a solution for this. My client’s website is going to need to be multisite, so the one that is used to be the main website will turn into a subdomain, and two copies as well as subdomains but with specific information regarding the location of the branch. The site uses webform module, for people who want to apply for a position within the company, they can send their resume. So the webform has a significant number of submissions. When I moved the site to the subdomain I ran into the problem as you described in your post. Now that I fixed it I cant figure why the attachments of the webform have a duplicate path, I mean, the files are stored in sites/{subdomain-name}/files/webform/attch/{file-name} but in the view of results where you see the link to download the file the link appears as sites/{subdomain-name}/files/sites/{domain-name}/files/webform/attch I wonder if you’ve ever ran into a similar situation and how did you fix it.

Thanks for posting this! Helped me out!

Drupal always being one of the best CMS has a number of pros for their users. It has alway active community which will try to solve your problem. One of the best example for it is the number of post being published with tag drupal each day and among them this post is one such. Custom Website Development