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.

multiple menus

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

Node Hierarchy menu


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 About??
    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:

Common header

Common footer

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).

News crawl

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


Dave Reid's picture

People should only be seriously evaluating or using Domain module if they are sharing content across sites. If your sites share common features, but not content, multisite is he way to go.

wjones's picture


wjones's picture

OMG, Dave Reid commented on my blog post, and I totally dismissed it! I met Dave at DrupalCon, he's like my hero! You're the man Dave, I'm sorry!

jamesm's picture

I'm having an issue with a site running Domain Access Module and Feeds Module. I'm suspecting that the two have resulted in the issue we're experiencing.

Our feeds which are being pulled into the sites via the Feeds Module are not updating automatically - with a caveat - You can see the most recent blog posts in the feed if you are logged in as an administrator.

I can't see anything wrong in the configuration for the Feeds Module which would cause the issue.

Do you have any gut feeling as to whether or not the Domain Access module may be contributing to the described behavior.


wjones's picture

In my experience with Feeds, I had some issues with cron. Basically, if I ran cron once, it would not pull the newest feeds until the next time. My solution was to run cron twice nightly, one after another, and have "Refresh" set to "as often as possible.

If you can see it when logged in, my first two guesses are 1) check your page caching, or 2) check permissions.

Maybe that helps?

kaceylu's picture

I found the entire Software Tailor team to very helpful and knowledgeable.
You help me understand the differences between the other systems on the market
and the software development

Marrakech's picture


siva kumar's picture

Just visited your blog. The layout is looking very colorful, fast loading.

Thomas's picture

We run 3 (soon there will be 4) sites with similar functions and structure. I think we have the same problems that you had. And I really considered to use DomainAccess.
But your article (and some experiments by myself) convinced me that I have to live with multi-site - even if this is a hell of redundancy in many respects (modules, permissions).

Thank you for this excellent article - it saved me a LOT of time!

Does Drupal 7 (or 8) promise any improvements in this area?

JJ McCorley's picture

I tried initially to set up multi site to create subdomains on my employers website, but couldn't get it to work at all - I'm no great coder, but can follow instructions, I find that most guides to multi site will only explain how to make separate domains, or will explain how to make subdomains in avery vague way that doesn't seem to work when I try. I would much prefer multi site as very little content will be shared between subdomains (only admin login details and possibly the occasional article posted to the main domain.
I am running Drupal 7, my host has a facility to create subdomains through the control panel, this works by treating a subdirectory as a subdomain, eg 'sub.example.com' is stored at 'example.com/sites/sub'
I assumed that simply making a second site through the multisite approach and placing it within the subdomain would be possible, but the only guides I can find require access to the linux command-line which I don't have.
ANyone have any ideas

kaceylu's picture

China English Tour is the largest
tour club in China.With decades of travelling experience, our club offers the most
comprehensive tours, from group packages, tailor-made private itineraries to hotel,
flight and train ticket booking services. Our club members are ready to help you.

Francis's picture

Which would you recommend for a Website & Mobile App combination? I would like to have the mobile vesion of the site scaled down, but still accessing and searching the same data used by the main website.
which would work better in this scenario? Domain Access or Multisite?

Kelly's picture

I'm a Drupal newbie and inherited a good-sized Drupal 6 site for my first. We have about 15 domains and are using the Domain Access mod. I'm a little confused because by using Views with custom displays and Panels with Variants, keeping content separate has been fairly easy. Like I said, four months ago I knew nothing about Drupal except that it was a cms. Though I am a front-end dev so maybe the time saved by seeking out such methods has blinded me to something easier!

Alain Jacquet's picture

Hey there
A very interesting discussion. I found this post through the Drupal Groups postings on Multisite.

I have a rather complex combination that I want to sort out:
1 Main website with subdomains (separate logins requried for those)
Main site must share login details with Site 2 on a different domain.

Main site and Site 2 are currently on different servers, but I could move them over to share the same machine. Currently they have two separate sets of code, and separate databases.
I do intend to set up uBercart to manage subscriptions to the two sites, but they will manage two different sets of applications.

Any suggestions?
Thanks for the interesting article.

Ted Best's picture

Thanks for the comprehensive breakdown. I am adding a 4th domain to our existing site... in the same boat and am leaning towards Domain Access.

Rajeev Kumar's picture

Well written use case for multisite. I was looking for advantage of it & came to your blog where it has been explained other. But still I will give change to Domain Access because I have my own complication like user permission to create sub-domain. Though I don't know how I am going to tackle other features such as custom logo, video links etc for their sub-domain. Lets see.

Christian Louboutin's picture
Movie-Chashme-buddoor's picture

Thanks for the comprehensive breakdown. I am adding a 4th domain to our existing site... in the same boat and am leaning towards Domain Access.

ram14's picture

This blog has lots of very useful information on it! Thanks for helping me.
Mobile News Gathering Solutions
System Integration service providers

meck's picture

I found this informative and interesting blog so i think so its very useful and knowledge able.I would like to thank you for the efforts you have made in writing this article.

Anonymous's picture

We provide high class driving training for all drivers, we also help you pass your test in first go. We professionals who will guide you in every way and make sure you are ready for your test. g1 test rules

Anonymous's picture

Toronto Limousine Service will make your wedding day limo service a positive one, along with offering you prom limo rental services, night out limousine. toronto limousines

Anonymous's picture

Search Appointmente - Our local lawyers are recommended and reviewed by locals. We understand how legal issues can stress you out, so take control on your legal matters and contact us.Legal

aliceseo's picture

I am really impressed with your efforts and really pleased to visit this post.I definitely appreciated every bit of it and I have you book-marked to look at new information in your web site.Stage Sets

Roberto O Hall's picture

Thanks for the interesting article. There are many people who want to know about this detail and i was also looking it. do my essay is a better choice too for the students.

CarlyPetr's picture

Drupal is absolutely one of the leading programming language today due to its flexibility. This post will definitely help a lot of developers (including us) in our website. Appearance and user-friendly features are important factors for a website, and learning Drupal is really an advantage. Although we are still working on our Drupal, we are gradually integrating it on our website. compression sleeves

Add new comment