On Friday 17 July 2009 2:44:30 pm Clemens Tolboom wrote: > On Thu, 2009-07-16 at 10:18 -0500, [email protected] wrote: > > sites.php was actually added specifically for this sort of issue, > > because the sites/ directory structure was too brittle. > > > > Of course, for the files directories in particular I have long since > > dropped using sites/<sitename>/files in favor of files/<sitekey>, which > > sidesteps the issue entirely. That doesn't need to change no matter > > what server the site moves to. > > What is your sitekey structure in case of a multi-site environement and > what when doing a staging scenario ie move production to a demo of > regression environment? > > (With D5 multisite I moved from the files/<sitename> to > sites/<sitename>/files to get rid of painfull all at once D5 updates.)
Anything recognizable to me will work. For example, on a D5 multi-site for a Chicago Pre-School program (http://www.virtualk.org/ and http://www.virtualpre-k.org) we used "vk" and "vpk" subdirectories. On another install where we're rolling out 40-50 micro sites all as third-level or fourth-level domains, we just use that part of the domain. (So foo.example.com and bar.example.com become files/foo and files/bar.) Drupal doesn't care what your files directory is or if it maps to a domain name; it just cares that you don't change it part-way through the site's life time. That's when stuff gets weird. -- Larry Garfield [email protected]
