Multisite Decision Flowchart

Events happening in the community are now at Drupal community events on www.drupal.org.
You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

There is much confusion about when to use what "multisite" technique. Sometimes Organic Groups is a better solution that full blown sites, other times there are complex shared database tables in mind. This page is meant to help people make decisions about what Drupal "multisite" solution is best for them.

The best way to show this will be with an actual, graphical flow chart. Let's start by listing out some questions and answers, plus pros, cons, or gotchas with various modules.

Flowchart Questions

Do you want a single userbase across all sites, or one userbase per site?

  • single userbase --> Domain Access, Organic Groups
  • per site userbase --> Standard multisite, Aegir

Modules / Recipes with Pros and Cons

Aegir

Automates one-click install of Drupal sites through a web interface. A layer on top of "regular" multisite, except that non technical users can create sites. Paired with one or more install profiles, can manage and deploy 100s or 1000s of Drupal instances.

Resources

Pros

  • non-technical end users can deploy new sites instantly

Cons

  • need a dedicated server
  • requires a high level of knowledge around command line, DNS, and other sysadmin-related tasks
  • need to build install profile(s) before it can be really useful (otherwise you just get a fresh unconfigured Drupal

Notes

Boris Mann: Aegir is awesome if you are going to run/deploy/manage/upgrade lots of sites. It can actually manage sites across multiple servers. It is also filled with kung fu, so even if it looks nicely graphical, NEWBIES BEWARE! You must really, really understand servers as well as have Drupal knowledge. If you're a hosting provider, enterprise, or institution...check it out!

Sharing the User Table

Sharing the user table: this is one method, using table prefixes, to share a single user base across multiple sites. Still needs one of a number of techniques to stay logged in across sites, if that is needed.

Resources

  • add
  • links

Pros

  • works on any multisite install on the same server.

Cons

  • you're so on your own if you try this

Shared content and single sign on

I'm after a number of different domains, although sub-domains will work too, that share the majority of their content and have a single user base. I want users to remain logged in between sites.

Resources

Pros

  • The Domains module is very functional, allowing you to configure site-specific or site-wide editors for publishing stories.
  • It's great for related sites that might share a lot of content, but have their own unique theme. For example, I have a ski, snowboard and skate site and if I have some news about a ski resort I can post it to ski and snowboard, but not skate.
  • By default all tables are shared, but you can also have site specific tables (not tried this myself yet).

Cons

  • I believe this will only work if all domains and sub-domains are on the same server.
  • You'll need considerable access to your server. The virtualhosts section of the httpd.conf file needs to be changed the DocumentRoot to be identical for all domains.
  • The SSO package is at risk of becoming marked as unsupported. However, for me it works fine.

Notes

The documentation for SSO is sadly lacking and the README only really discusses the situation where you don't have Domains installed. I think this boils down to the fact that it sort of works out of the box with Domains if you get as far as visiting the SSO admin pages.

Add your module or recipe description here

Short, concise description

Resources

  • add links to project page
  • and external how to, etc.

Pros

  • this is a pro

Cons

  • this is a con

Notes

[Some User] Here are notes and opinions. Sign them with your username

Multisite

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: