Using Domain Access for Drupal CMS

18 March 2013

Berlin: This is a powerful module that allows multiple subdomains to co-exist within the same Drupal instance, and for every piece of content in the system, it provides a special field that allows you to define which domain(s) the content can be “affiliated” with. Content can belong to one single domain or to multiple subdomains. Domain Access then uses Drupal node access configurations to ensure that each and every request for a node page (e.g. node/1) is only accessible at the domain(s) to which it belongs.

There are many caveats to the Domain Access module’s architecture because, by itself, it lacks support for some basic modules that almost all sites require (e.g. Context, Boost, SecurePages, AuthCache, etc.). All these modules require some path configuration; e.g., a Context will normally be conditioned to be activated in some paths, but with Domain Access every subdomain represents a different Country content but the path for a page will remain the same. Taking an example for news page we can have multiple URLS: or but these modules will not understand differences of content based in our subdomain parameter and extra modules as Domain Context will be required to resolve this issue. The same problem will arise with all the modules that condition them behavior based on path criteria). Even Drupal core does not recognize the domains as a context for paths conditionally showing blocks.

Very different will be with OG having URLS like: or the paths criteria could determine country and page without extra dependencies. However, in several cases there are companion adapter modules, such as Domains Views, that make it possible to filter content (in this case, by way of a contextual argument) that correspond to some specific domain. Simply put, Drupal is not designed to understand multiple domains as different pages; what Drupal understands well are URIs (relative paths) to your domain. Domain Access has a tendency to end up being a complicated module to understand requiring a plethora of add-on modules and configurations to handle the conditional content display on a per-domain basis for each country-specific feature you add to your sites.

The third approach we evaluated and finally went with is based on the popular module OG (Organic Groups)

OG was used to great effect within the intranet distribution Open Atrium. In the following paragraphs we explain in more detail how we employed the OG module.

Drupal Web Development Berlin

News Archive

  • WordPress Development in Berlin
  • Drupal Development in Berlin
  • Joomla Development in Berlin
  • eCommerce Magento Berlin
  • Web Development Berlin
  • Web Design Berlin
  • jQuery development Berlin
  • Zend framework development Berlin
  • Airline IBE GDS Integration Navitaire Berlin
  • Airline IBE GDS Integration Aamadeus Berlin