<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
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 <div><br class="webkit-block-placeholder"></div><div>Would hate to have to go through sysadmin-level coding contortions to override a newly rigid default. Or am I misunderstanding the thread?</div><div><br class="webkit-block-placeholder"></div><div>Laura</div><div><br><div><div>On Dec 9, 2007, at 6:31 PM, Khalid Baheyeldin wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><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></blockquote></div><br></div></body></html>