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.