We were recently approached by a client who wanted to create two sites to serve different audiences but with vast amounts of common content. The same group of people would be responsible for the upkeep of both sites and the desired solution would allow content to be shared with great ease.

We initially considered a Drupal multisite install, but the idea was rejected in favor of the Domain Access module. The rationale was simple: with a traditional multisite configuration, we would have had to create custom code to determine where content would be displayed, whereas this is the primary functionality provided by Domain Access. The other attractive element was having both sites on the same code base, with the creation of additional sites handled via the Drupal database itself.

The build strategy

We began by creating a standard Drupal install and adding menus and content as if we were creating a single site. Domain Access can be added at any point in time, and all existing content will remained published on the domain served by the existing site. This means that no rework was required, and it allowed us to deliver the client's requirements in a phased manner. Once we were comfortable that the initial work was completed, we introduced Domain Access, which requires some updates to the settings.php for proper operation. These changes can be made before or after the module has been enabled:

Configuring Domain Access

Domain Access ships with a number of modules and, for the suite to be useful, a number of them need to be configured. What we found as the minimum required for the commonest functionality is shown below.

This setup allows all the sites to have their own configuration settings, site-specific Views, themes and, where required, unique database tables. To create additional domains, visit admin/build/domain/create. You'll note that you're asked to enter a subdomain rather than a domain -- while Domain Access only supports subdomains, the issue can be overcome with some Apache configuration magic (more on that later). Now that you have a domain created, visit admin/build/domain/view to configure your new domain. The operations presented will depend on the modules you have enabled; most relate to standard Drupal site configuration.

One significant exception is the "Table prefixing" tab, which allows you to setup different tables for different domains in cases where you don't want the data to be shared. For example, our client wanted separate menus on both sites, so we opted not to share the menu and cache_menu tables. When we created the new tables, we than chose to copy the existing table because the second site's navigation was a subset of the first. Had this not been the case, we could have just created a new table rather than copying it. Of course, you'd then have to login to the appropriate subdomain to edit the relevant menus.

Content creation

Once Domain Access is installed, content creation offers a few new options which allow you to determine which domain items appear on. Content can be added and removed from a domain with the same ease as content being published or unpublished by Drupal itself. Similarly, content can be processed on a batch basis by visiting admin/domain/content/all.

Deployment

Once development has finished, you're ready to deploy your new site. Launching a site utilizing Domain Access is the same as a single site install with one exception: you'll need the ability to update Apache's VirtualHost configuration and, depending on your hosting company, you might not have it. Remember: whenever you need to deploy a site using this design pattern, always check with your hosting provider to see if they can support your requirements. As a general rule, you'll need to add either all Domain Access configured domains to the primary VirtualHost's ServerAlias, or else point all relevant DocumentRoots to your single installation of Drupal. Once these changes have been made, your new site(s) will be live and you can freely share content between them with just the click of a button.

Until next time...