[development] Files directory on installation usability fix not quite usable. ; )
HedgeMage at binaryredneck.net
Sun Dec 9 16:33:37 UTC 2007
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.
> 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
More information about the development