Many of us are too much used to the comfort of full access to the server. We need to remember that there is a huge number of Drupal installs on various shared hosts that do not offer any SSH access. No git, no drush. I myself still have quite a few sites at Rackspace Cloud and the ability of uploading modules once and then just running /update.php is a huge time saver.
vacilando On Sat, Nov 13, 2010 at 18:21, Randy Fay <[email protected]> wrote: > I'd rather do a > > Take site offline > cd /site/base > git pull > drush updatedb > and test the results > put site online > > on each site, than do > > Take all sites offline > cd /site/base > git pull > cd into each sites dir one by one > drush updatedb > test each > Put them online as it works out > > The time is about the same. The risk is much lower. > > You can still run them all of the same code repository; I have no issues > with that. > > -Randy > > > On Sat, Nov 13, 2010 at 9:58 AM, <[email protected]> wrote: > >> My main reason for using multisite is time. I have 20 domains. If I am >> going to keep 20 Drupal sites 'in the green' (core/module status) with each >> having their own code base, it's 20x the effort. >> >> >> On 11/13/2010 11:30 AM, Randy Fay wrote: >> >> My unpopular opinion is that multisite is completely unnecessary for the >> vast majority of installs and has major drawbacks. The only fundamental >> advantage of multisite is that that it saves some disk space (does that >> matter?). But it has fundamental downsides: >> >> - It closely couples the database updates of many sites. (When you do >> a module or minor version update, you have to do the update and test on >> all >> the sites at that exact time. If you're doing it "right" it means that >> many >> sites may be offline until you're done. >> - It takes your filesystem risk and instead of having one site at risk >> at one time, they're all at risk. So if you have a new module you're >> introducing or an upgrade that has a bug it unfortunately affects all >> sites. >> - The files directory has to be managed exactly right; and it better >> not be sites/default/files. >> >> IMO, multisite and database prefixing were for the old days before we had >> unlimited accounts and disk space was free. >> >> That said, if you know exactly *why* you're doing multisite and you want >> to tie sites together, then that's fine. But "because Drupal does it and it >> seems cool" is not a good reason. >> >> Aegir is fundamentally a multisite idea, and it deals with all these >> problems. It's a maturing approach to doing multisite quite well, and many >> people are very happy with it. That's a good reason for doing multisite, and >> it has all the issues above dealt with. >> >> -Randy >> >> >> > > > -- > Randy Fay > Drupal Module and Site Development > [email protected] > +1 970.462.7450 > >
