Many modules store a file path of an arbitrary file relative to index.php, like sites/oldsite/files/somefile.extension. This is bad practice, but many modules do it.
This means that when an alternative sites directory is used (because of a change of domain or movement to development sandbox) the file paths are broken. On the file system, this can be fixed with a symlink from oldsite --> newsite in the sites directory. However then file_create_url('sites/oldsite/files/somefile.extension') returns http://newsite/sites/newsite/files/sites/oldsite/files/somefile.extension, instead of the functional http://newsite/sites/oldsite/files/somefile.extension.
This patch rewrites most of file_create_url() to add checks for all possibilities. It works if public downloads are enabled, but probably not if private downloads are enabled. That system may need to be refactored for these changes, or vica versa.
| Comment | File | Size | Author |
|---|---|---|---|
| file_create_url.patch | 1.83 KB | Bevan |
Comments
Comment #1
owen barton commentedThis is a dupe of http://drupal.org/node/98824 I think - we might want to look at which approach is better, but they essentially do the same thing :)
Comment #2
Bevan commentedI've since worked out this problem is more complex and needs some fundamental changes to file api;
The path stored in the files table MUST be relative to the files directory. This requires co-operation from contrib developers, quite a bit of refactoring in the file api, and testing. Perhaps something for the new OO file api for d7?
There may also be valid exceptions requiring that file paths not relative to the site files directory are stored in the files table. I can't think of any, but if there are, then this might require some sort of flag in the files table, like 'relative' where 0 is the files directory for the site, 1 is the drupal root, and anything greater than 1 is for future possibilities and/or user-defined locations.
Changing to bug as it's what this is. Without some fix to this issue, multi-site configurations don't work as expected.
Comment #3
ptamas commentedwould this be why I can't see the theme screenshots in admin/themes for my sub.main.com site where the site is located in /sites/sub.main.com ? might it also explain why reviewers in the conference module can not seem to download the papers they are supposed to review?
-peter
Comment #4
Bevan commentedThe work going on http://drupal.org/node/98824 is a better approach and more progress is going on there