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.. <div>
<br></div><div>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 :)</div>
<div><br></div><div><div>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.</div><div><br><div class="gmail_quote">On Sat, Nov 13, 2010 at 6:21 PM, Randy Fay <span dir="ltr"><<a href="mailto:randy@randyfay.com">randy@randyfay.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I'd rather do a <br><br>Take site offline<br>cd /site/base<br>git pull<br>drush updatedb<br>and test the results<br>
put site online<br><br>on each site, than do<br><br>Take all sites offline<br>cd /site/base<br>git pull<br>
cd into each sites dir one by one<br>drush updatedb<br>test each<br>Put them online as it works out<br><br>The time is about the same. The risk is much lower. <br><br>You can still run them all of the same code repository; I have no issues with that.<br>
<font color="#888888">
<br>-Randy</font><div><div></div><div class="h5"><br><br><div class="gmail_quote">On Sat, Nov 13, 2010 at 9:58 AM, <span dir="ltr"><<a href="mailto:jeff@ayendesigns.com" target="_blank">jeff@ayendesigns.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div text="#000000" bgcolor="#ffffff">
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.<div><br>
<br>
On 11/13/2010 11:30 AM, Randy Fay wrote:
<blockquote type="cite">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:<br>
<ul>
<li>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.</li>
<li>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.</li>
<li>The files directory has to be managed exactly right; and it
better not be sites/default/files.<br>
</li>
</ul>
IMO, multisite and database prefixing were for the old days before we
had unlimited accounts and disk space was free.<br>
<br>
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. <br>
<br>
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. <br>
<br>
-Randy<br>
<br>
<br>
</blockquote>
</div></div>
</blockquote></div><br><br clear="all"><br></div></div><div><div></div><div class="h5">-- <br>Randy Fay<br>Drupal Module and Site Development<br><a href="mailto:randy@randyfay.com" target="_blank">randy@randyfay.com</a><br>
+1 970.462.7450<br><br>
</div></div></blockquote></div><br></div></div>