Multi-headed Drupal

by Larry Garfield

One of the strengths of Drupal is that it's not just a tool for building a single website. It can be used equally well for managing multiple companion sites together. This capability has existed for many years, but is not always well understood. And in true Drupal fashion, modern Drupal has several different options available for users looking to run a series of Drupal sites together, each with its own trade-offs.

Perhaps the key point to consider when planning a large-scale Drupal rollout is that multiple semi-independent sites does not necessarily imply multiple Drupal installs. In fact, it may not even mean multiple sites at all. What appears to be a separate site may actually be just a trick of Drupal's access control system. There are many factors to consider, including how unified the ownership of the entire site will be, whether it needs to appear to site visitors as one site or many sites, how disparate the theme and layout will be, what the content editing workflow will be, and whether or not content needs to be shared between sites and sections.

illustration by Michael Mesker

Let's survey some of the major ways of breaking up an online presence with Drupal, and what their pros and cons are.

For context we'll consider a common use case, that of a university with several colleges and departments under each one. Depending on the school, each college or department may have a great deal of autonomy regarding their web presence or the university may have a centralized web strategy. The same concept applies to a large corporation with several divisions, too, as well as smaller organizations with only a handful of "different" sites.

Separate installs

Sometimes the best strategy is to not unify sites at all. In this case, any similarity between different sites is largely coincidental. If there will be a large number of sites then some automation tools such as Drush or Aegir may make spinning up new sites easier, but from a site building perspective they are different sites.

The advantage with this approach is that each site is completely autonomous. That can be good if each department should have complete or nearly complete control over their own web presence. Common theme elements may be shared by different sites, but nothing in Drupal enforces that.

Another advantage of this approach is that it doesn't require all sites to even be running the same Drupal version. If an organization (such as a school) is standardizing on Drupal, but not on a specific Drupal implementation, then it may over time build up a collection of sites managed by different departments in Drupal 6, Drupal 7, and eventually Drupal 8 simply because of when they were built. This is the only strategy that allows that to happen, since different major-versions of Drupal cannot cohabitate in the same code base.

On the flip side, that autonomy comes at the price of consistency. Different sites may not work the same or function the same, and certainly cannot be managed uniformly. Upgrades must be done on each site independently. Administration cannot be centrally managed, as users will need to log into each site individually to make changes, review content, etc. While most such environments will have a 3rd party login system, such as LDAP, a separate user account is still needed for each department site.

Another consideration is content sharing. For the most part, the answer here is "no". While it's possible to pass data back and forth using Feeds, full replication of nodes between sites is not a simple task, even in Drupal 7. Aggregator-style integration is possible, showing just title links to nodes on another site, but tighter integration requires significantly more effort. It may also have implications for SEO (due to duplicate content), editing rights (which cannot be enforced cross-site), keeping content changes in sync, and so forth.

In this approach, each site could live on a separate domain but could also be installed in a subdirectory on a single domain.

For example, Chicago Public Media maintains a number of Drupal sites, including Chicago Public Media, WBEZ.org, and Vocalo community blogs, as well as sites for some of their more popular shows such as This American Life. All run on Drupal, but are managed separately as they are separate architectures with separate content. That can provide a lot of flexibility, while still allowing the organization to standardize on a single in-house technology platform.

Features-based installs

As a slight variation of separate installs, it's possible to run multiple installs with the Features module. For those not yet familiar with it (and you should be), Features is essentially an automation tool for those pieces of configuration that Drupal allows to be mirrored to code so that they may be checked into version control. These days much (but sadly not all) of Drupal's configuration can be feature-ized. The most effective configuration components to manage this way include content types, views, panels, and image styles.

Even if sites are physically separate, they can be made more similar by building a common set of Feature modules that are deployed (and then kept up to date) on each site. Good candidates here are event node types and related views, news node types and related views, etc. That sort of standardization can help facilitate moving administrators between sites, as well as planning for later integration into a single Drupal install.

The caveat is that not everything is "featurizable". Most notably, block configuration does not handle Features well at all. Much of Drupal's configuration sits half-way between content and configuration, which makes, say, menu items non-featurizable. If you want to share layout configuration between sites, planning to adopt either Panels/Panels Everywhere or Context/Boxes as your layout mechanism from the get-go (and standardizing on one or the other) will avoid a lot of frustration.

With this approach, a "Calendar" feature may be built that contains an Event node type, a couple of views, maybe a Panels page or two, and possibly an image style (if events will have images). That bundle of configuration can then be installed on multiple sites to give them all identical functionality.

Taken to its logical conclusion, a series of features can be built together into an install profile or distribution. In this case, a new site can be created 80% completed or more by simply installing the distribution, which will enable all of the standard feature modules as well as pre-set some common non-featurizable configuration.

That's the approach Palantir took for building microsites for the Field Museum. The Field wanted to be able to quickly spin up microsites for different exhibits with a very similar configuration and theme. We built a custom install profile, leveraging features, that allowed them to create new exhibit sites quickly and on-demand.

Multi-site

infographic describing a multi-site system

For years Drupal has had the ability to run multiple sites off of a single install base. In this case, there is a single copy of Drupal's code base but each college or department has its own settings.php file, which points to a different database. From a site builder perspective, this is almost the same as having separate installs. Every site must be configured independently, but every site may also be configured independently. Each site may also live on its own domain or in subdirectories, although the latter requires some symbolic link trickery and editing the Apache .htaccess file to make work.

The advantage here is for the server administrators. There is only a single copy of the Drupal core code base, and typically a single copy of most modules, that is shared by all sites. That makes it easier to update a module as it needs to be updated only once. However, it also means that you cannot easily update a module for just one site without updating it for all of them. Whether that's a good trade off or bad depends on the scale of the installation, number of sites, and how complex each site could get.

On the plus side, common custom modules and custom base themes are much easier to manage since they have only a single instance. That's especially beneficial for base themes, as a multi-site installation of this sort will frequently have a common base theme and then each department will have a specific subtheme that customizes the look and feel for that specific site. Careful planning and coordination is necessary to pull that off, however, to minimize duplication of work.

Another less obvious advantage is memory usage. Servers running opcode caches (APC, eAccelerator, XCache, etc) will cache the compiled version of every PHP file in memory to reuse for all sites. This cache is keyed by the file so 20 separate installations of Drupal would have 20 copies of common.inc in memory whereas a multi-site install would have only one, resulting in a considerable memory savings for the server. That means fewer resources used and less money spent on server hardware.

Palantir built such a setup for Washington University St. Louis' College of Arts and Sciences several years ago. It actually predated the development of Features, but allowed each department within the college to have its own site on a commonly managed base.

Domain Access

infographic describing a domain access system

In practice, however, at Palantir we've found that most of our clients that think they want multiple site installs actually don't. Most of the clients we work with that want "multiple sites" — especially universities — want a single management experience but want to make it appear as if their content was spread out across multiple domains. In that case, the go-to solution is the Domain Access suite.

Domain Access (DA) is actually an access control module that uses the node grants system. With DA, a site administrator can point multiple domains to a single Drupal install. Drupal will then self-filter any nodes in the system to display only on specific domains. There is still a single database, single code base, single user base, and single content pool.

On the plus side, that is great for system administration. There is one code base, one database, one user base. It also makes content sharing between sites really really easy, since there is only one site. Exposing a node on multiple domains is a simple checkbox. That makes, for instance, views that "roll up" news items from multiple domains quite straightforward to do. At the same time, each department appears at its own domain (english.example.edu, for instance) for visitors to the site.

Domain Access is also one of the easiest content sharing mechanisms available, since content is not actually "shared". Any node can be associated with as many domains as desired, allowing it to appear "in" those sites. But it's still a single node in the system, so edits apply globally.

On the downside, because there is only one site there is only one structure of content types, views, panels, etc. Content type definitions cannot vary because there is only one Drupal installation. Views are, technically, cross-domain although filters are available for "current domain" (similar to "current user"). The same is true for Panels configurations. Also, of course, each sub-site maps only to a domain, not to a path.

Domain Access does allow quite a bit of domain-specific configuration, however. Almost any configuration variable (those that use the core settings form) can be set per-domain, including the active theme. Since the themes can be different, and themes can still have a common base theme, it allows for lots of flexibility in terms of how different each site can get. The Domain Path module can also sort out duplicate path aliases, such as "about" (which many domains may have).

Other caveats with Domain Access

  • Do not use insert module or any other insertion filter or module that grabs the absolute URL. This can become a problem if all your content is proliferated on a testing server where the URL is different than the production server.
  • Domain Access is primarily intended for separating user display of content into domains. While it can be used as an access control system, that is not its primary function. For advanced edit-access controls, Workbench is a more robust and less complex solution.
  • As Domain Access uses the core node grants system, it may have complex interactions with other grants-based modules. This is a limitation of the node grants system.
  • Single-sign on is standard, since all sites in the installation share users. However, cookie security limits shared login cookies to sites that share a top-level domain (e.g. example.edu, english.example.edu and german.example.edu may share an .example.edu login cookie, but myexample.edu may not.)
  • SEO can be a concern because of the potential for duplicate content. Using rel=”canonical” in tags can help address this.

Some Domain Access sites built by Palantir include Interlochen Center for the Arts, Lexar and Barnard College.

Organic Groups

infographic describing an organic groups system

Organic Groups OG, properly pronounced as a single word (like "Ogg the caveman"), is an older module, but it was rewritten from the ground up in Drupal 7. It's now built almost entirely on Drupal 7's Entity and Field systems and is far more flexible than ever before for clustering content within a single site to simulate multiple "sites".

With OG, each node (any entity, really) can be made into a "group", and then other nodes can be associated to one or more groups. Depending on the configuration, that could impact navigation, path aliases, theme selection, and so forth, to give the impression of different "sites".

In Drupal 7, OG is also now able to allow per-group administration in a sane fashion. That means, for instance, users can edit nodes of a certain type in certain groups, but not in other groups.

While OG is very flexible, it also has its limitations. Like Domain Access, the fact that it's a single Drupal site with a single database means that content types are still uniform across the entire web presence. While OG can vary the site theme, it cannot change other settings and configuration. Its setup process is also not entirely intuitive. Hopefully that can be improved through some well-applied UI work in the future.

Palantir has used OG for clients like The Marine Corps Association, who needed to be able to manage content for the Leatherneck and Marine Corps Gazette magazines as well as the Marine Corps Association Foundation. While each section of the main site and the Foundation site each has a distinct original look and feel, the back-end of both sites are the same, making it easier for administrators to wrangle content and manage their workflow.

One site to rule them all

Of course, there's no reason why a large-scale Drupal install has to be complicated and multi-headed. Many large and complex Drupal sites work just fine as a single site on a single domain. Frequently, what is a separate "site" in a client's mind at first is not actually a separate site, just a section of a single site. That can be the case when, for instance, academic departments will be migrated one at a time to a new Drupal site. Although they are migrating in pieces, if there is a consistent theme and the department appears as just a subdirectory in the URL, then it's not really a separate site.

If each department needs its own content editors, which is often the case, the Workbench module provides a simple, powerful way to chop up a site on the content management side without affecting the front-end structure.

Palantir built such a unified site for the University of Chicago Law School in Drupal 6. Although the law school has several departments the site is managed by a single editorial team with a single design so there is no reason to break it up either for administrators or for site visitors.

Mix and match

When planning a large-scale Drupal rollout, it's also possible to consider combining strategies. For instance, both Domain Access and Organic Groups can run on their own Drupal instance that just so happens to be multi-site... and have other Drupal sites hosted on it as well. Workbench can be used for administration of content on a single Drupal instance independently of whether it uses DA or OG, and can easily be enabled on multiple instances on the same install as well. As of this writing Workbench does not integrate with either module, so for instance Organic Groups or Domains cannot be used to define "sections" in Workbench, but such integration is possible.

The caveat, of course, is data sharing. Drupal is not really designed to share nodes between separate Drupal instances. While there are methods to syndicate nodes from one site to another (the Deploy module, the Views Atom/Feeds Atom suite, Migrate, etc.), they all have limitations. As a "lite" option, the Aggregator module, in core, allows only titles and summaries to be pulled into one site but still link back to the original site. In many cases that is sufficient, and in that case whether each Drupal instance is in the same multi-site install, in separate installs on the same server, or half-way around the world from each other is functionally irrelevant.

infographic describing an multisite domain access system

Palantir recently built such a hybrid with multi-site and Domain Access for a network of public advocacy organizations. A single Drupal install runs four separate instances using multi-site, but some of those instances also run Domain Access for different student organizations. Each student organization can therefore share content, content types, Views, and so forth with other student organizations but still be presented as its own site to users. For site administrators, however, there's only one single Drupal code base to have to manage. In all, one code base powers four Drupal instances and, to the site visitor, around 150 distinct domains.

Conclusion

Drupal offers a variety of solutions to address multiple sites with shared and separate content. As with all things Drupal there is no right solution — just options for your specific needs. Evaluate your goals and make decisions based on them; you may find that Domain Access is a better fit for your content editors or a multi-site setup is much easier to manage for your system administrators.

Comments

DA in a multi-language environment is still a hard one due to missing variable API support (the one used by i18n). While not ideal, it can be solved with some t() function hardcoding in the theme.

We use DA to circumvent the limit on our shared host based on the number of DB tables.

Actually, you can use the insert module with by adding $conf['insert_absolute_paths'] = FALSE; to the settings.php file.

There is another option not mentioned here (possibly because it is not very recommendable? Indeed the Domain-Access solution seems to offer more or less the same set of advantages and trade-offs):

Drupal has a little-documented feature that allows some-but-not-all tables to be shared, by overriding the table-prefix per table.

In this way the node table and related tables (e.g. Field API) can be shared, whilst the user table and related tables are unique per instance. Or vice-versa; Users and profiles can be shared while content-related tables are unique per domain. Or various other combinations.

The biggest trade-off here is that a thorough understanding of the DB schemas and the relationships between tables is required to determine which tables should be shared and not. And that making a shared-table not-shared or vice-versa is non-trivial if you don't get it right before the new schema gets to the production site.

That is also an advantage though because the decisions about which data is shared or separated can be much more granular.

One advantage over the DA and OG options is that no additional modules or configuration is required, so this could be done right now on Drupal 8 sites, for example. And the technique is not prohibitive when needing to upgrade the website to a new major Drupal version. Although all the instances (if you are separating enough tables to justify calling each one it's own "instance"!) must of course use the same version of Drupal and contrib modules which they share tables for.

We left out table sharing because it is effectively a hack. We did one site using that model once, and it ended up as more trouble than it was worth. (It was back before Domain Access existed, which is the approach we would recommend for that site now.)

The problem with table sharing is that tables rarely correspond to the slices of data that you want shared. You also run into copious issues with ID clashes. For instance, sharing Field tables but not sharing the node table is almost guaranteed to lead to nid collisions. And if you share the node table, it means that all nodes are shared between sites, without exception, rather than just nodes of a given type or that have a certain flag or whatever. If you actually want all nodes to be shared, then odds are you want a single site in the first place.

Add to that difficulties in upgrades. If you run an update hook that touches a shared table, you have to run it on one instance, then edit the module to remove that update hook and run it on the second site. Otherwise the update hook gets run twice on the same table, which is rarely safe.

We no longer recommend table sharing for any clients, as there are many better solutions (as documented in this article). Even web services-based content replication is a better solution than table sharing these days.

Thank you for the excellent article. I'm wondering whether your admonition against table-sharing also applies to sharing the users table and other tables related to users, roles, and permissions. This is one suggested technique for setting up a network of sites that share users but not content.

Also, the Single Sign-On module is not yet available for Drupal 7. Is there any other way to achieve single sign-on with either a multisite install or Domain Access?

User sharing is actually what we did for the aforementioned client, by sharing tables. Again, more trouble than it's worth in this day and age.

Domain Access, because it's only a single Drupal instance, already has a fully shared user base. No SSO needed. This is not an area I have dug into in much depth, but Drupal.org uses the home-grown Bakery module. That may be an option to look into.

I wish all Drupal articles were as informative yet simple to understand. There would be a lot more Drupal developers in the world. The illustrations are top notch.

Thanks for the insight. I've built a lot of multi-sites and OG sites. But right now I have one that I'm doing for my college (as just a student volunteer since I am an officer in a club). It's for the clubs and organizations, which have no web site capabilities, online event calendar, etc.

They want to be able to edit their section/site, change the look of their section/site, and share events to the main site. Everyone's events would show in their area, but the main site would show all events.

I've been going around and around as to what exactly to use. Multi-site seemed a bit much since most will have maybe 2-5 pages and then a bunch of events. I'm starting to lean towards an OG setup, but wasn't sure how to get their domains to work with that. I'm definitely going to check out Domain Access. It's not one that I have used before.

If each organization needs its own subdomain, then Domain Access and Multi-site are really the only serious options. If each group is only a half-dozen pages then Multi-site is definitely overkill.

That said, I don't see why you need a separate subdomain for 5 pages. That sounds like a super-basic OG setup to me, much like http://groups.drupal.org/.

Since BrowserID can automatically perform a javascript-based login upon a user visit to any page, I'm pretty sure it can be used for persistent logins across domains. Although, sure, it wouldn't actually be a persistent session, but firing a new session immediately without the hassle of a login form might be sufficient. You might need to refresh the page (think of the stack exchange solution to autmatic cross domain logins).