[development] Files directory on installation usability fix not quite usable. ; )

[Khalid Baheyeldin]

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 figure
> > 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 with
> 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.conf
> <?php
>
> $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 lifetime
> 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 externally
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...
URL: http://lists.drupal.org/pipermail/development/attachments/20071209/e5b054eb/attachment-0001.htm