I'd like your opinions.
Client has commissioned 9 of their sister organizations sites to be redesigned/redeveloped as Drupal sites (actually 1 already is Drupal). They want each site to be independent, but share some content, such as a common events calendar -- which I intended to do with Views/FeedsAPI. They have asked that it be done as a Drupal multisite, with only shared codebase. I believe that they think multisite is the only way to share content. Client is non-technical (no web specialists) and not familiar with Drupal, but wants to be able to maintain it themselves.
I think that this is a bad idea. As I start the development process, I keep imagining having to explain certain things to them -- i.e. multisite file paths and URLs. As someone newish to multisite, I find myself getting tripped up by it -- writing them out as I would for a standalone site, by habit. So, I can imagine that they will find it confusing. I keep trying to find tricks to simplify this, but no matter the trick (mod rewrites, symlinks, apache rewrites), it won't create a consistent approach for all scenarios and modules. This in on top of me needing to teach them to use Drupal as content publishers (user roles, permissions, nodes, block management, etc.)
I am not so far entrenched that I cannot start developing each site as a standalone install. (Having started development elsewhere, I am having to rewrite all the multisite paths in content/db anyway.)
Here are the drawbacks that I see for a non-technical, non-Drupal client:
-
Risk of breaking sites when doing updates. (Updates can be tricky when they don't play nicely.)
-
Lax in performing updates, which will affect all of the sister organizations.
-
Confusion about paths -- Imagecache, WYSIWIG, content embedded.
-
Additional work required to split off a site, if one organization wants to host elsewhere. (Has already happened.)
-
Harder to maintain a duplicate testing environment, i.e., syncing databases.
Thoughts?