[development] Multisite risks (formerly multisite complication)

[Iñaki Lopez]

IMO, it is a mix of both cases, Randym, Jeff.. You still do need to the same
number of system updates when you are upgrading 20 sites or a multisite, and
Randy, not necessarely all modules should go into sites/all/modules, many of
them should only go to sites/custom/modules, so you don't need to update all
sites when developing a custom module, and you still have to update all the
sites when updating a module with major changes using the sites/all path..

Multisite is not only for limited account or disk space, it may help also
sharing files (when non-security related), configuration, and many other
things (that yet still can be done without multisite, I know), but you do
have access from one site disk space to another, if this is your use case.
Multisite can't be used on all setups, sometimes you need different versions
of the same module and need to split completely from the multisite, because
you can't have two modules (one in sites/all and other in sites/custom)..
well, you may have, but expect the unexpected :)

Multisite, under my point of view, is needed in some cases, and useless in
others.. You just need to know when it fits your requirements.

On Sat, Nov 13, 2010 at 6:21 PM, 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/be143476/attachment.html