[development] Files directory on installation usability fix not quite usable. ; )
kb at 2bits.com
Sun Dec 9 15:33:32 UTC 2007
On 09 Dec 2007, at 6:30 AM, Larry Garfield wrote:
> Emphasis on the "properly". :-) I had been going with the conventional
> of sites/<site>/files, but when I went to merge two sites into a
> to deploy them realized that wouldn't work; the path that is stored into
> 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
> document to *not* use the sites/ directory for multi-site installs unless
> 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,
...etc. One directory per site. Then files would be "sites/s1/files". A
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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the development