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

[Gaele Strootman]

Khalid Baheyeldin wrote:
>
>
> On Dec 9, 2007 12:15 PM, Khalid Baheyeldin <kb at 2bits.com
> <mailto:kb at 2bits.com>> wrote:
>
>     On Dec 9, 2007 11:33 AM, Susan Stewart
>     <HedgeMage at binaryredneck.net <mailto: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>
>         > <http://site1.example.com <http://site1.example.com>>, and
>         s2 www.example.com <http://www.example.com>
>         > <http://www.example.com> and s3 is example3.com
>         <http://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 <http://example.com>' => 'site1',
>       ' example2.com <http://example2.com>' => 'site3',
>       'example7.com <http://example7.com>' => 'mydir5',
>       'site3.example.com <http://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.
Just what I was thinking:

http://drupal.org/node/98824#comment-648260

No symlink clutter, no need for CLI access.

Now, would it be possible to somehow manage this file through Drupal
(perhaps just as install.php does with settings.php)?

Gaele

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20071210/524d324d/attachment-0001.htm