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... > > >
