I thought that keeping separate per-domain File Systems would be a good idea,
so I set up individual File system paths in Domain settings, e.g.:
Drupalfiles/domain_0
Drupalfiles/domain_1
In User Settings user pictures path is defined relative to a given
File System, e.g.: avatars (relative to Drupalfiles/domain_0)
User xxx registers on domain_0 and uploads her picture to Drupalfiles/domain_0/avatars
When visiting domain_0/users/xxx the image is correctly referenced as
domain_0.dot.com/Drupalfiles/domain_0/avatars/picture.png
When visiting domain_1/users/xxx the image is incorrectly referenced as
domain_1.dot.com/Drupalfiles/domain_1Drupalfiles/domain_0/avatars/picture.png
I can fix that, but... is this only for users, or is it a more general problem?
Afterall, keeping separate File Systems might not be such a good idea.
Comments
Comment #1
agentrickardI think this is a more general problem.
However, the hook_url_alter() patch might fix this issue. Right now, it is only looking to alter paths for node links, but it could be made to alter links for image calls as well.
Look at the logic in domain_url_alter(). Possibly there needs to be a second routine to check to see if the path is to the files directory.
Comment #2
agentrickardYou could also, I think, fix this at the server level by aliasing all paths to /files.
Comment #3
agentrickardWe might also see about setting the path in the {flies} table to an absolute path.
Comment #4
agentrickardThis is, potentially, a huge issue. I'll have to dig in deeper, as file paths may not work correctly.
Comment #5
agentrickardVery close to a solution.
However, it requires a very small patch to theme_user_picture().
So, the question is, do we simply abandon the ability to change files directories? I hope not...
Comment #6
skizzo commentedWould that solution address only the user picture problem?
if one creates the files and file_revisions tables for every
single domain, would that solve the problem at large?
Comment #7
agentrickardI had hoped -- naively -- that simply altering the 'file_directory_path' would magically make this work, but it doesn't.
The table prefixing would possibly solve this problem, but you may still have issues for files viewed on one domain but hosted in the files directory of another domain.
To the web server, a file on example.com/files/1.jpg is identical to one.example.com/files/1,jpg -- the trick is telling Drupal how to write the path to the file.
I spent about 4 hours on this yesterday, and the only solutions that I see are quite complex.
theme_user_picture() and it's interplay with theme_image() requires a patch. But the bigger problem is modules (like User) that create subdirectories inside of the /files directory.
If you are using 'files' and 'files2' and 'files3', we would need a mechanism to ensure that a 'pictures' directory exists inside each of those. Doing so would require some extra configuration of the module and lots of debugging.
Add to this the fact that the 'files' directory path may be a string like 'sites/default/files/domain1', which makes deducing the path to the file more difficult.
What happens, it seems, is that Drupal stores the path to the file in the database. It then appends the 'file_directory_path' to the filepath. In some cases, you end up with paths like:
/files2/files/myfile.jpgIt is fairly easy to deduce how to strip a string like that and make it point to the path
/files/myfile.jpgWhere things get complex is when the path looks like this:
/files2/files/picture/user-2.jpgOr, even worse:
/sites/domain2/sites/domain1/picture/user-2.jpgI think it may be best to remove this feature from the Domain Conf module and propose that a Domain Files module be planned for people who want the feature.
Comment #8
agentrickardI will be removing this feature from the next release of Domain Conf. It just isn't stable.
I have created a feature request for this functionality here: http://drupal.org/node/198131
Officially marking this a "won't fix" to indicate that this feature is being dropped from the first release.