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

agentrickard’s picture

I 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.

agentrickard’s picture

You could also, I think, fix this at the server level by aliasing all paths to /files.

agentrickard’s picture

We might also see about setting the path in the {flies} table to an absolute path.

agentrickard’s picture

Title: File sistem cross references » File system cross references
Category: support » bug
Priority: Normal » Critical

This is, potentially, a huge issue. I'll have to dig in deeper, as file paths may not work correctly.

agentrickard’s picture

Very 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...

skizzo’s picture

Would 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?

agentrickard’s picture

I 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.jpg

It is fairly easy to deduce how to strip a string like that and make it point to the path /files/myfile.jpg

Where things get complex is when the path looks like this:

/files2/files/picture/user-2.jpg

Or, even worse:

/sites/domain2/sites/domain1/picture/user-2.jpg

I 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.

agentrickard’s picture

Status: Active » Closed (won't fix)

I 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.