[development] Multisite risks (formerly multisite complication)

[Tomáš Fülöpp (vacilando.org)]

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 <randy at randyfay.com> 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, <jeff at ayendesigns.com> 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
> randy at randyfay.com
> +1  970.462.7450
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20101113/2ae8fa54/attachment-0001.html