By sambtaylor on
It would be great to have clear instructions and info about upgrading multisite installations. There are so many nodes related to people saying they have struggled with this that it makes me afraid to start a multisite installation. In any case, is it known to be a simple, easy process with clear instructions (which my search didn't turn up)?
Comments
=-=
The problem with multisites it, instructions would only cover CORE. not contributed modules. That being said, and as wiith any other update or upgrade, you should consider doing it on your LOCAL system first before messing with a production environment. This will help you find any problems before you shut your site down.
otherwise the instructions are exactly the same as any other type of upgrade.
place site in offline mode, replace files, run update.php
with multisite all sites update.php must be run.
I take the extra step of disabling contrib modules before updating but thats just my preference.
_____________________________________________________________________
Confucius says:
"Those who seek drupal answers should use drupal search!" : )
Thanks for the response. .
Thanks for the response. . .
. . .so after backing up everything, and putting up the new files, you simply need to go to each domain address/update.php
example1.com/update.php
example2.com/update.php
example3.com/update.php
etc.??
And do all these updates run off the one update.php in the main installation or do you need to put it in each site folder?
Are you saying it would be difficult to run the update for the contributed modules? Would it be any different than what you would have to do to update each of them anyway, any more difficult? I am simply beginning to wonder if multisite saves you time or adds you stress, though I love the idea of it?
And, I really WANT to run all this locally first, but I have been unable to find anyone who can help me figure out why MAMP isn't working on my computer. http://drupal.org/node/179326
More generally, Misunderstood, I appreciate all your responses here, to me and to everyone else. You do a great job helping all of us climb the castle walls. Thanks
=-=
yes
yes
I just prefer the extra step of disbaling contrib modules before I do anything major to my DB. I do this for non multi sites as well.
no, but even when I am updating a module, I disable it.
I don't employ multisites much any more. Drupal core is so small that it doesn't seem to make sense. I do however use multisite to do this one task.
One code base for a dev site (sandbox) and production site. so i have dev.mysite.com and mysite.com working off the same codebase at all times. This allows me to test modules on a seperate DB away from production site. play with themes, away from production site. And when I'm ready or satisfied I make change or add modules to the production site.
I don't use a Mac. Thus I can't help with that. I'm a windows users and use WAMP or apache2triad
_____________________________________________________________________
Confucius says:
"Those who seek drupal answers should use drupal search!" : )
Right on
Your use case is the only one I use multisite for as well. If I was a provider of managed hosting for simple similarly preconfigured sites (ie they all use the same set of modules), I might use it for that too maybe.
I think more people need to understand this - especially newbies. If you don't understand the detailed nitty-gritty of multisite setups but think you somehow still need it, chances are that you don't actually need it.
Multisite makes the quickest, easiest, most scriptable part of site management easier at the expense of making the harder parts even harder and reducing your flexibility for when you upgrade sites.
--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal
Multisite makes the
That's a nice, windy assertion. Care to back it up with any facts?
Nope
It's self evident, and I don't (yet) care enough to add anything more.
Feel free to supply a nice windy assertion of your own though.
--
Anton
Heard of
Heard of sites/example.com/modules? SVN sandboxes, for that matter?
The reasons for the multisite config schemata are equally obvious, have been reviewed and discussed by a few more people than yourself, and are the prevailing opinion. That opinion certainly has its flaws, but those flaws are minor compared to a bald assertion that the schemata are wrong that doesn't back itself with an argument other than "its self-evident."
I therefore don't (yet or otherwise) care to discuss it here, either. You offer an unsupported premise: prove it or shut up.
OK then - now that I've got enough time to respond...
I am well aware of how multisite works and what you can do with it, and well aware of how hard newbies can make it for themselves. I have spent a lot of time helping newbies with multisite over the last few years.
Some background:
I DO use multisite for different 'instances' of the same site (the usecase mentioned in the previous posts) eg versions for different developers, test instances, and the production instance. I do use different settings.php configs for each instance, to override site variables, and reroute mail from test instances etc. I do use svn:externals to pull in each sites modules - contrib and custom modules can have different branches that can be pulled in independently for testing. I script syncing of our svn branches with with the drupal.org CVS repo. I have scripted svn vendor drops and merging, so that when a new minor Drupal version is released it won't clobber custom code changes (no custom patches used at the moment though). I have scripts to deploy different development branches to any instance and synchronize uploaded files and databases around.
Multisite does help with all this, but doing it all with separate codebases wouldn't be that big a deal. All this file manipulation is the EASY bit - it is very easily scriptable and version controllable. And changes can easily be reversed etc.
The database is the HARD bit as you are already know. It is very difficult to manage your data and settings in the database in the same flexible way as different parts of the database need to flow in different directions. There are a lot of very smart people (way smarter than me) banging their heads against this problem and developing deployment and staging modules etc g.d.o is awash with discussions about that topic.
Multisite gives you one codebase for multiple sites, you only need to upload Drupal once. But you still have to manage databases separately, and things get even hairier once once start sharing tables. And now add major version upgrades into the mix. The database schemas need to match the codebase version. You need to take all your sites down at once, you need to make sure that all the modules for all the sites have updated versions available, backup all the databases, and run the upgrade script individually for each site before bringing them back up again. How does that not reduce flexibility? What if one site is using a module that can't be upgraded yet?
That is manageable (and useful) if the sites are just different instances of the same site. But putting very different sites with different modules under the same Drupal instance just to save uploading more than one codebase is false economy.
That is why I said multisite makes the easy bit a little easier and can make the hard bit harder or less flexible. And that should be self evident to anyone who has been through that. I'm not sure how the obviousness of separate codebases being more flexible to upgrade isn't apparent to you.
Which of my points don't you agree with?
To anyone who has managed multisite set ups and managed Drupal upgrades - I can't see how those points aren't self evident.
You seem to have blindly assumed my point was "multisite is bad - don't use it" which is not the case. It is an important Drupal feature that I rely on myself, but many people don't understand it and try too hard to make use of it where they probably don't need to.
--
Anton