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

[Susan Stewart]

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.

<snip>
> Maybe we should formalize that as the advocated solution. This works
> for all UNIX like systems. Not sure about those hosting/developing
> on Windows though.

Actually, it doesn't.  It works for all of us pros on our own servers 
just fine, but for Joe Hobbyist who is running a multisite install on 
cheap shared hosting (where he has FTP access, but not SSH), this 
approach is impossible.  Without any actual statistics available, I'm 
willing to guess that this is common enough not to be dismissed as an 
edge case.

Susan