Jump to:
| Project: | ImageField |
| Version: | 6.x-3.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
Issue Summary
I developed my website at clientname.example.com and set the File system path to sites/"clientname.example.com/files"
Once I had everything ready to launch, I moved the site to clientname.com and changed the File system path to "sites/clientname.com/files"
However, all my imagefield images still retain their original filepath
[filepath] => sites/clientname.example.com/files/filename.jpg
So all image paths break, and there seems to be no way to update the File system path. Emptying cache does nothing.
This makes 'filepath' unusable in situations where the site needs to move. As a workaround, I was able to reconstruct the filepath at the template level by using the 'filename' value.
file_create_path($field['filename'])
But this is kludgy and shouldn't be necessary.
It seems like there are a lot of modules involved here, so this may not even be imagefield's problem, but I don't have this problem elsewhere.
Comments
#1
This problem runs deeper than imagefield. Drupal's upload.module also stores the file_directory_path() in the files table. This is problematic on any drupal site where you may want to change the file_directory_path(). The best solution is to write small script that selects everything from the files table and replaces the file_directory_path() component.
#2
This should really be dealt with. Is there a thread on this somewhere? Is there a new method in the works for a future version? I'd like to follow any developments.
It seems like this script could be attached to the admin/settings > submit form, to run automatically if the file system path has changed. It could even be an option e.g. (update all old file paths [x]) in case there is a reason why someone might not want to do this.
#3
No there is not a solution currently. Each module implements how it saves file on its own, and how it intreprets the data it gets from the file tables (whether it prepends file_directory_path or not.)
So the issue is not so simple. You can try to determining how all the modules do it, and which is the best way to support all people's use cases. it's quite a task.
#4
I agree with the complaints here. Moving sites from dev to live often have this problem. I've found that the only solution currently is to simply store files outside of the sites directory. Store the files in a location unchanged from dev to live, and not dependent on the site name at all.
Say your site is named 'www.foo.com'. Store your files at 'files/foo' rather than 'sites/www.foo.com/files'.
#5
In order to keep things portable, I've decided to change my sites directory from, e.g. "sites/www.example.com" to "sites/example". This also reduces the length of my file path from "sites/www.example.com/files" to "sites/example/files".
Then, to get Drupal to properly address the domain on my multi-site installation, I just go into /sites and create a "www.example.com" sym link that points to "example":
ln -s example www.example.comIf I need a dev version of the site I can create another symlink called dev.example.com and use a different database or whatever.
Good things about this method
a) file path's are unharmed by domain change.
b) file paths are shortened and cleaned up (I never liked having the full domain repeat in my urls).
c) each client is still contained within a single directory (I'm anal about this for some reason).
Not so good
a) a little confusing
b) kind of messy, perhaps there is a way to do this automatically with mod_rewrite or even an AliasMatch directive in my httpd.conf
c) may require special privelege on some servers?
To be honest, I'm really surprised there isn't an official Drupal accepted/enforced method. It seems like this is the kind of thing that really needs to be standardized sooner than later.
#6
While I agree with you all about the path in the db issue, I'm going to set this as won't fix. it's not really a problem with imagefield in most cases. although I will try to design around it or fix it a lower level.
#7
In a multisite installation i faced the same problem.
My DB had the old path for the images ex: sites/olddomain/files/images/imagename.jpg
I only wanted to change the part "sites/olddomain" in every record, with the new string "sites/newdomain" to fix the problem and make the images appear again.
So, with the MySQL function REPLACE(); i achieved what i wanted.
MySQL Querry:
UPDATE files SET filepath = REPLACE(filepath,"sites/olddomain","sites/newdomain");
Then the images appeared again.
#8
This is my standard practice now also.
Works so far for me.
Not sure what the alternative totally graceful solution could be.
#9
Having the same problem as well. Will try the symlink, but would love to see a better solution.
#10
this not only affects imagefield but any module that allows file-handling in any way. i was really surprised that the filepath is hardcoded in table files (new to drupal). anyone who decides to switch on drupal will stuck on this, sooner or later. if you move your drupal-installation around or go on multisite.
another problem is that some modules offer a path input (even tokenized) and some don't. so eventually you have to remember all those places where to put which path for what module...
i hope there will be a unified interface for all modules that handle files some day. all modules "register" at the unified file interface and get their own filepath from it. just like module "pathauto", where you can define "paths" for each node-type.
you can configure all your db-stuff and set shared_tables, but when it comes to files, you run into one big file-directory. on some hosts php runs as another user, so your ftp-user can't move files afterwards you try out something. there is no such thing like a "master file interface". module filefield_paths has its "retro active update", this should be put into a higher level within drupal to make sure, all users are able to control files.
#11
I am just revisiting this problem once again - This time I am trying to make a local copy on my (linux) desktop from my working public site, to do some redevelopment.
Most people move sites by exporting the SQL from the old site and reimporting to the new. The .sql file is human readable text, so I am going to do a search & replace using a text editor before reimporting. This has the advantage over an sql approach of turning up unexpected cases to change. I have identified the following candidates so far
1) The files list (field filepath in table files)
2) The site name itself - many of the node links and references refer to the full site name. There are also references in many log files and in the messaging store. It is not always appropriate to change to the new site name, so it needs to be thought about on a per-table basis.
Settings to change are found in the file settings.php, but also in the contact form (admin/build/contact) and files directory (admin/settings/file-system). I am sure there will be others.
This question arises so frequently I think I shall try to create a handbook page in the new structure, in the hope that others can add to this.