On Wed, 17 Oct 2007 11:44:09 +1300 Anton anton.list@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