One consideration with multisites is that if you allow a user to use PHP in Drupal (block visibility, input format, etc.) then they will be able to read the settings.php for all your sites, and thus connect to all the databases. Aegir uses 'cloaked' credentials to handle this, putting the database details in the vhost files, and then just pulling those into the settings.php file for Drupal.
Regards Steven Jones ComputerMinds ltd - Perfect Drupal Websites Phone : 024 7666 7277 Mobile : 07702 131 576 Twitter : darthsteven http://www.computerminds.co.uk On 13 November 2010 22:58, Cameron Eagans <[email protected]> wrote: > In any case, multisite is a good thing, I think. Updates are a piece of > cake, but you should keep two codebases around. Put all of your multisites > on codebase A and let them run for a while. When updates are available, pull > the updates down on codebase B and move your site directories over one by > one and run update.php. It's a good process, and it's easily scriptable. It > also happens to be the same process that Aegir uses (more or less). > Thanks, > Cameron > > > > On Sat, Nov 13, 2010 at 13:33, Chris Skene <[email protected]> wrote: >> >> All the previous points about Multisite and its advantages/disadvantages >> are valid, however in your case, as you plan to zap the database regularly >> and it doesn't sound like data integrity is important, I would probably >> start with multisite as well. >> I will add, that if you are using APC to improve performance, multisite >> has big performance benefits over separate codebases, as APC will reuse all >> the files. The benefits are partly lost with separate code bases. >> Either way, however, I would use git to manage the platform off a separate >> repository. >> Chris Skene >> [email protected] >> >> On 14/11/2010, at 2:56 AM, [email protected] wrote: >> >> I don't know. I'll try that out. In thinking this through, another >> question sprung to mind: >> >> If these categories are going to be various demos, with the intent of >> pushing a database overwrite hourly to repair any pummeling done via users >> playing with the admin panel, are there risks in them sharing the same code >> base with production multisite sites? >> >> On 11/12/2010 09:38 PM, Christopher Skene wrote: >> >> Does having a site folder called sub.domain.category_1 work? You may need >> a symlink in your root folder to this folder, called "category_1". >> >> On 13/11/2010 12:29 PM, <[email protected]> wrote: >> >> Right, so sub.domain/category_1 would run off the same code instance as >> sub.domain/category_2, but separate db's >> >> On 11/12/2010 08:23 PM, Christopher Skene wrote: >> > >> > >> > So you want different sites on each categor... > >
