[development] Files directory on installation usability fix not quite usable. ; )
laura at pingv.com
Mon Dec 10 03:10:11 UTC 2007
The /sites/* solution makes sense for many multisite configs, I
feel ... Just as long as there's an admin-configurable way to
override the default. E.g., for private files configurations I've
always preferred going above the webroot, such as "../sampledirectory
Would hate to have to go through sysadmin-level coding contortions to
override a newly rigid default. Or am I misunderstanding the thread?
On Dec 9, 2007, at 6:31 PM, Khalid Baheyeldin wrote:
> On Dec 9, 2007 12:15 PM, Khalid Baheyeldin <kb at 2bits.com> wrote:
> On Dec 9, 2007 11:33 AM, Susan Stewart
> <HedgeMage at binaryredneck.net> wrote:
> Khalid Baheyeldin wrote:
> > 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://site1.example.com >, and s2 www.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
> out what directory the symlink points to -- an unnecessary step that
> would definitely slow down my workflow.
> Symlinks is just what works today, and acceptable for installations
> not too many sites. Granted, you get the bramble bush that comes
> with it
> and that can be unwieldy.
> Perhaps the indirection should be formalized in a different way,
> with a
> map of some sort (domain -> directory), either in a master file under
> sites, or in the database (slow).
> $map = array(
> // Site domain/subdomain => site ID and
> 'example.com' => 'site1',
> ' example2.com' => 'site3',
> 'example7.com' => 'mydir5',
> 'site3.example.com' => 'otherdir2',
> Once a site gets an ID/Dir, this does not change at all for the
> of the site. Domains/Subdomains can be changed at will, such as when
> moving a site from test to live, or from multisite to
> standalone, ...etc.
> The above indirection scheme will solve another thing: 404s for
> visible paths. Using a unique site id for a directory will prevent
> external 404s
> from happening if you move the site to another domain.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the development