Multi-headed trong Drupal

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.

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

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

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

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.

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.