On Dec 9, 2007 11:33 AM, Susan Stewart <HedgeMage@binaryredneck.net> wrote:
Khalid Baheyeldin wrote:> <http://site1.example.com >, and s2 www.example.com
>
>
> 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
> <http://www.example.com> and s3 is example3.com
> <http://example3.com>, ...etc.
My sites/ folder on my multisite installs is cluttered enough, thanks.
Also, if I want to make changes to a site, I would have to first figure
out what directory the symlink points to -- an unnecessary step that
would definitely slow down my workflow.