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

[Laura Scott]

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?

Laura

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  
> 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/f9c97ea0/attachment.htm