On 09 Dec 2007, at 6:30 AM, Larry Garfield wrote:

Emphasis on the "properly". :-) I had been going with the conventional wisdom

of sites/<site>/files, but when I went to merge two sites into a multi-site

to deploy them realized that wouldn't work; the path that is stored into the

files table is then bound to the domain the site is on, which is no good

because the domain changes from staging to production. So if we document

sites/default/files for single-site installs, we need to in the same breath

document to *not* use the sites/ directory for multi-site installs unless you

want to make moving to a new server to be a PITA.

Perhaps a decoupling of the paths from the domain is in order.

There is a way to do it today with symlinks: under "sites/" we have s1, s2, s3,
...etc. One directory per site. Then files would be "sites/s1/files". A symbolic
link then makes s1 be site1.example.com, and s2 www.example.com and s3
is example3.com, ...etc.

If you then decide to use .net instead of .com for s1, the file paths do not change
at all. They remain the same.

What this does is have one level of indirection, so we don't run into these
hard coded domains in file path names.

Maybe we should formalize that as the advocated solution. This works for all
UNIX like systems. Not sure about those hosting/developing on Windows though.