[support] multiple sites on same install was: Re: Upgrade to Drupal 5?

[Ivan Sergio Borgonovo]

On Wed, 17 Oct 2007 11:44:09 +1300
Anton <anton.list at gmail.com> wrote:

> > - you fix/tune stuff in one place

> Or more accurately: you can fix/tune a small fraction of stuff in
> one place. Most fixing/tuning seems to be driven out of the
> database/admin screens rather than the codebase.

I use pgsql frequently and I generally have to fix modules to make
them work with pgsql. Recently I had to fix the watchdog function in
core for the same reason.
Modules in different sites tend to have different versions. Adding
sites to the same code base may mitigate these problems.

> > - you upgrade in one place

> You still need to upgrade each sites database individually.

You still don't have to upgrade all the code bases.

> > - you save some space

> A very minor benefit with the current cost of disk space. The Drupal
> codebase is pretty small, and could quickly get dwarfed by the
> database size or uploaded files/images.

Absolutely true unless your site is on your Linux router ;)

> > cons:
> > - less tedious but more complex/risky install/upgrade process

> Yep. You also need to upgrade every site at the same time - which
> could be a pain if each site has different clients or module
> requirements.

Core should stay untouched, can't modules be divided in /all/ and
site specific modules?
Shouldn't the overhead of having them in the all directory be
negligible if they are not activated?
I'd keep the ones that all the web sites need in all and then the not
shared ones in a different place.

I agree that putting everything together you risk to kill everything
at one time when you upgrade/change some stuff.
I wouldn't put the codebase of different clients in the same place
too.

> > any hands-on experience? comments?

> The codebase management is the easily scriptable and version
> controllable part. It is the database management that is the harder

I can't see how it can be easily scriptable and version controllable.
I see maintaining different code bases a management burden.
I tweak something in a module (no matter how I would like to avoid to
touch work maintained by someone else, but sometimes you've to do it).
Then I've to replicate the same change everywhere or a) I'll forget
b) changes in other modules won't be in sync.

It is trivial but it is one more management step.

> part of managing multiple Drupal sites.

> Multisite still has its uses though. I use it to manage different
> instances (eg dev, test, production) of the same site so that each
> instances unique settings.php stuff can be version controlled along
> with the other instances in the same codebase. That way I can check
> out the codebase onto any of our servers or virtual hosts and it
> will pick up the appropriate database connection and other settings.

> My (personal) opinion is that if you don't fully understand how
> multisite works and why you need it, then you probably don't need
> it. Others might feel differently though.

mmm let me understand... you share *all* the codebase including
modules etc... with the exception of settings... just to edit the
production settings before checkout and let it land on the server as
you need it and not as on your local copy?

Just thinking how multisite could be exploited.

thx

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it