This seems to be Acquia's Enterprise Drupal Gardens service, which explicitly does not allow ad-hoc addition of client-selected modules. They have a set of approved modules which can be selected and configured, but custom code, or even un-approved contrib modules, are verboten. Not an environment I would want to have to deal with, I must say.<br>
<br><div class="gmail_quote">On Mon, Aug 20, 2012 at 6:31 PM, Owen Barton <span dir="ltr"><<a href="mailto:drupal@owenbarton.com" target="_blank">drupal@owenbarton.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Another consideration in forcing multiple disparate sites into a single docroot (that don't otherwise want/need to be a multisite) is that it introduces some security tradeoffs, because the sites often cannot be effectively isolated from one another: all the sites normally end up running under a single system user account (and can read each others settings.php for example) - meaning that if one site is compromised then they are all are.<br>
<br>Thanks!<span class="HOEnZb"><font color="#888888"><br>- Owen<br><br></font></span><div class="gmail_quote"><div><div class="h5">On Mon, Aug 20, 2012 at 2:57 PM, Ryan Cross <span dir="ltr"><<a href="mailto:drupal@ryancross.com" target="_blank">drupal@ryancross.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
With a bit of experience from a client who basically did the same thing, and also reading between the lines a bit, I think this an awkward mix of cost-based and policy-based decision making from people not knowledgable about the details. <div>
<br></div><div>For an Acquia managed cloud service, they charge an additional (substantial) $ figure for each additional webroot. So, it seems people are either told/sold or come to their own conclusion that they can save money and support multiple sites with a single webroot and Drupal's multisite capabilities. However, the client doesn't seem to always understand that this effectively slows down their innovation and delivery cycles by requiring any deployments of code to go out to all their sites (and thus requires extensive testing across multiple sites for even a small change intended only for a single site). This is also coupled with a common sense, risk mitigation policy, which proposes that there is a vetted / approved set of code that can be used and any deviations are a no-no. </div>
<div><br></div><div>A few points of advice: </div><div><ul><li>As mentioned, make sure that the client understands what they are getting into. </li><ul><li>Point out how the perceived cost savings of this approach will likely limit their options down the line and/or cost them more over all.</li>
<li>Advocate heavily against this approach, but address their concerns in alternate ways.</li></ul><li>Suggest/insist that they define a policy/procedure around getting new modules approved and custom modules & patches approved as well. </li>
<ul><li>Don't forget to point out that Acquia's support model is specifically there to cater for ALL modules (including custom code and patches), so in this way they are "covered"</li><li>Also indicate whether they have the capabilities to review and judge code and their ability to turn around approvals on new code (they will probably realize they don't have this and back off a bit)</li>
</ul><li>Find other "providers" who will working with the client (perhaps internal staff members) and will also be subject to this new approach and get them to support and reiterate the concerns with this approach. </li>
<ul><li>You might be able to figure out who originally proposed this and get some understanding of their motivations/rationale. Then either help them understand the problems this will impose and/or help address their motivations with alternative solutions. </li>
</ul></ul></div><div><br></div><div><br></div>
<br></div></div><div class="im">_______________________________________________<br>
consulting mailing list<br>
<a href="mailto:consulting@drupal.org" target="_blank">consulting@drupal.org</a><br>
<a href="http://lists.drupal.org/mailman/listinfo/consulting" target="_blank">http://lists.drupal.org/mailman/listinfo/consulting</a><br>
<br></div></blockquote></div><br>
<br>_______________________________________________<br>
consulting mailing list<br>
<a href="mailto:consulting@drupal.org">consulting@drupal.org</a><br>
<a href="http://lists.drupal.org/mailman/listinfo/consulting" target="_blank">http://lists.drupal.org/mailman/listinfo/consulting</a><br>
<br></blockquote></div><br>