Drupal Redesign: Domain Access vs. Multisite

This post is part of a series about our implementation of Drupal during the redesign of www.museumofplay.org and the launch of the Strong.
Read the first post here.

One of the first problems I encountered while working on the Strong websites was how to connect the websites together using Drupal. Domain Access module and Multisite installations are two different approaches. Here's my own struggle with this choice, and why I eventually went with a Multisite installation.

There are six distinct sites that share common features. I used subdomains in development, but we eventually settled on the following six domains:

• thestrong.org
• museumofplay.org
• icheg.org
• toyhalloffame.org
• libraryandarchivesofplay.org
• journalofplay.org

At first glance, the Domain Access module looked very promising. I began implementing it for our sites, but after some struggling, I decided it wouldn't work for us, and switched to a Multisite installation.

Here's why:

1. We like things different

I should point out that our Drupal site was not going to be like most other typical Drupal installations. For example:

• Our site is primarily content-driven, with a rigid hierarchy of copy-edited pages
• There are no registered users except for administrators
• Comments are universally disallowed
• Homepages are heavily customized
• There is not a lot of "news" or fluid content, except for the Press Room

The Domain Access module is geared towards a more community-distributed content authoring sort of website, which we are not. That may have factored in.

2. Too many menus

What are the primary links? To get around this, I created 6 Primary Links menus for the 6 websites. And with over 150 pages for all the sites, the combination creates a looooong and difficult administration for menus. It's so hard to know which menu you're in, since it's all crammed together in the drop-down list.

I also was looking to use the Node Hierarchy module to build the site structure. This created yet another convoluted menu:

Tedious.

3. Namespace collisions

The sites have lots of content that is named in parallel. For example, several sites have an "About" page, a "Things to See & Do" page, a "Collections" page, and a "Research" page. As content development progressed, this naming actually became more and more parallel. This caused two problems.

1. Crazy confusing content administration
   Granted, Domain Access does have its own admin listings that separate out each domain's content. Which is fortunate, because the default Content administration page becomes nearly unusable. Something like this happens:
   
   Which brings me to my next point.
2. Depressing Pathauto aliases
   My preferred way of generating path aliases was to use Node Hierarchy's tokens, which use the node title. I wanted (and, you could say, "needed") neat and pretty URLs for the site sections. In fact, my themes used the site sections to control colors and tabs. So I wanted URLs like /about-us, /see-do, /collections, /see-do/exhibits, etc.The problem is that Pathauto requires unique aliases. So, if I created www.museumofplay.org/about first, my attempt to create www.icheg.org/about would in fact create www.icheg.org/about-0. Then all the lower level pages in that section would have that ugly 0, like www.icheg.org/about-0/faq.You'll find, actually, that in the example site for Row Eleven Wines, posted as a case study for Domain Access, they got around this by inserting the Domain name into the path. So the About page on the Row Eleven Wines parent site is http://www.rowelevenwines.com/about; the About page for Pinot Noir is http://www.roweleven.com/pinot-noir/about; and, for Stratton Lummis, it is http://www.strattonlummis.com/stratton-lummis/about. This solution wasn't going to work for me.In my attempts to get around this limitation, I went so far as to start writing some mod_rewrite madness that would remove a site id from the beginning of the path. So, www.museumofplay.org/about would redirect you to www.museumofplay.org/1/about, www.icheg.org/about would send you to www.icheg.org/2/about, and so on. But I quickly learned that this was a flawed solution, caused all kinds of problems (paths for the lower level pages were becoming www.icheg.org/0/0/about/faq), and created a house of cards.

4. The house of cards

The paths were the last straw. With 6 big, complex websites being developed, stability became an important factor. All the workarounds I was exploring to meet my requirements were hack-ish solutions, and would have become this monstrous "house of cards", wherein one small change or bump would break ALL the sites. At least with 6 separate websites, if one goes down, 5 are still up, and that's 83% (approximately).

So, I changed my approach and went to a single code base, Multisite installation.

The Multisite Installation

I thought I'd talk here a little bit about what parts of the sites are shared, which led me to the Domain Access module in the first place, and how I worked around them.

There were two primary shared components, a common header and footer, and the "News Crawl" on the homepages.

This header and footer appear on every page of every site:

The HTML and the menus for these components were created by a custom module that I wrote. The defaults were all the correct forms of the links, so simply enabling the module would insert the menus in the correct place. This saved me from adding the same 20 menu items 6 times...

The other shared component was the "News Crawl", a box on the homepage with short news messages (that don't crawl, incidentally).

This I built using a crazy combination of CCK, Views, Views RSS, and Feeds module. It has a central administration page on the parent site, and all sites import items from a feed. (More about this in another post)

Besides that, users and other tables are pulled into a shared database in the settings.php file. Here's a peek at my settings.php file:

$db_prefix = array(
  'default'              => '',
  'users'                => 'drupal_shared.',
  'role'                 => 'drupal_shared.',
  'users_roles'          => 'drupal_shared.',
  'sessions'             => 'drupal_shared.',
  'sequences'            => 'drupal_shared.',
  'workflow'             => 'drupal_shared.',
  'workflows'            => 'drupal_shared.',
  'workflow_access'      => 'drupal_shared.',
  'workflow_states'      => 'drupal_shared.',
  'workflow_transitions' => 'drupal_shared.',
  'multisite_search_dataset' => 'drupal_shared.',
  'multisite_search_index'   => 'drupal_shared.',
  'multisite_search_sites'   => 'drupal_shared.',
  'multisite_search_total'   => 'drupal_shared.',
);

Users and roles were shared, but permissions were not. This is because I have different modules/features enabled on different sites, and didn't want to give everyone the same access. This is potentially a major pain, though. Enabling a module on every site requires setting permissions for every site—which is easy to forget.

One last thing—shared search. Since 3 websites became 6, we wanted search to be integrated between sites, so that no content that was rearranged was lost. I ended up resurrecting an abandoned project called Multisite Search to do that part for me.

Shared Sign-on/Single Sign On was looked at and desired, but it was again rather unstable and complicated, threatening another "house of cards" installation, so I abandoned it.

The Verdict

My struggle with this business was wrapped up about 9 months ago. I'm sure that in that time I've learned some more tricks and would have tackled some of these problems differently. I'm also sure that some of these modules have changed and matured since then. But when it came down to it, after evaluating the pros and cons of both approaches, Multisite was the way to go for us.

Next post: Themes and sub-themes