On Friday 17 July 2009 2:44:30 pm Clemens Tolboom wrote:
On Thu, 2009-07-16 at 10:18 -0500, larry@garfieldtech.com 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 larry@garfieldtech.com