<br><br><div class="gmail_quote">On Dec 9, 2007 12:15 PM, Khalid Baheyeldin <<a href="mailto:kb@2bits.com">kb@2bits.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Dec 9, 2007 11:33 AM, Susan Stewart <<a href="mailto:HedgeMage@binaryredneck.net" target="_blank">HedgeMage@binaryredneck.net</a>> wrote:<br></div><div class="gmail_quote"><div class="Ih2E3d">
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>Khalid Baheyeldin wrote:<br>><br>><br>> On 09 Dec 2007, at 6:30 AM, Larry Garfield wrote:<br>><br>>> Emphasis on the "properly". :-) I had been going with the<br>>> conventional wisdom of sites/<site>/files, but when I went to merge
<br>>> two sites into a multi-site to deploy them realized that wouldn't<br>>> work; the path that is stored into the files table is then bound to<br>>> the domain the site is on, which is no good because the domain
<br>>> changes from staging to production. So if we document<br>>> sites/default/files for single-site installs, we need to in the<br>>> same breath document to *not* use the sites/ directory for<br>>> multi-site installs unless you want to make moving to a new server
<br>>> to be a PITA.<br>><br>> Perhaps a decoupling of the paths from the domain is in order.<br>><br>> There is a way to do it today with symlinks: under "sites/" we have<br>> s1, s2, s3, ...etc. One directory per site. Then files would be
<br>> "sites/s1/files". A symbolic link then makes s1 be <a href="http://site1.example.com" target="_blank">site1.example.com</a><br></div>> <<a href="http://site1.example.com" target="_blank">http://site1.example.com
</a>>, and s2 <a href="http://www.example.com" target="_blank">www.example.com</a><br>> <<a href="http://www.example.com" target="_blank">http://www.example.com</a>> and s3 is <a href="http://example3.com" target="_blank">
example3.com</a><br>> <<a href="http://example3.com" target="_blank">http://example3.com</a>>, ...etc.<br><br>My sites/ folder on my multisite installs is cluttered enough, thanks.<br>Also, if I want to make changes to a site, I would have to first figure
<br>out what directory the symlink points to -- an unnecessary step that<br>would definitely slow down my workflow.<br></blockquote></div><div><br>Symlinks is just what works today, and acceptable for installations with<br>
not too many sites. Granted, you get the bramble bush that comes with it
<br>and that can be unwieldy.<br><br>Perhaps the indirection should be formalized in a different way, with a <br>map of some sort (domain -> directory), either in a master file under <br>sites, or in the database (slow).
<br><br>map.conf<br><?php<br><br>$map = array(<br> // Site domain/subdomain => site ID and<br> '<a href="http://example.com" target="_blank">example.com</a>' => 'site1',<br> '<a href="http://example2.com" target="_blank">
example2.com</a>' => 'site3',<br>
'<a href="http://example7.com" target="_blank">example7.com</a>' => 'mydir5',<br>
'<a href="http://site3.example.com" target="_blank">site3.example.com</a>' => 'otherdir2',<br>
);<br><br>Once a site gets an ID/Dir, this does not change at all for the lifetime <br>of the site. Domains/Subdomains can be changed at will, such as when<br>moving a site from test to live, or from multisite to standalone, ...etc.
</div></div></blockquote><div> <br>The above indirection scheme will solve another thing: 404s for externally<br>visible paths. Using a unique site id for a directory will prevent external 404s<br>from happening if you move the site to another domain.
<br></div></div>