I realise that without the following additional information the title question is too broad.

I have multiple sibling Drupal 7 sites with their own domains that I wish to consolidate into a single site, whilst to some degree retaining their apparent separateness. The rationale is discussed in this blog post, but to summarise:

  • The sites have been developed in parallel and share many features
  • Cross site search indexing would be much simplified by a single database
  • Maintenance of a single site would be less costly
  • Updates and new features could be rolled out simultaneously across sites
  • The single, [incidentally] simplified and documented site would be easier to hand over to another developer

From the approaches considered in these two excellent but dated appraisals from Atchai and Palantir I had initially identified Spaces as my preferred, maintainable solution, but an apparent shift in usage, and seemingly low overall usage of Spaces leads me to question my assumptions.

Googling shows a dearth of recent articles on the subject, and d.o usage shows a decline in the weekly installs for the spaces module, which implies that people are taking a different approach.

Spaces Weekly Usage graph

Domain Access, however, is on the up:

enter image description here

Does anyone have any recent experience that would help?


I believe I have settled on an entirely different preferred solution - multisite.

For my particular situation, my priorities are derived from having to hand over the multiple site setup to another developer (with unknown resource/ability). I believe that with this in mind my question contained a couple of false assumptions, namely

  • that a single site would be simpler to hand over to another developer
  • that therefore maintenance costs would be lower than retaining multiple sites

The site will probably not have to share much content, and even fewer users, between sites so the main crossover is providing a shared search index. I have already solved this by separating the search functionality via aggregation (in an admittedly circuitous fashion). There are more powerful and efficient multiple site options involving Apache Solr or similar, but having separated search from the sites, these options are still open, and need only be implemented in one place.

A single site with multiple domains must necessarily make use of Domain Access, Spaces, Organic Groups or some combination of these. It may, therefore, be a single site, but it is not a simple site. Even if the documentation I provide with the site is perfect, the inheriting developer may encounter complications or complexities when maintaining or extending this more sophisticated site. Domain Access, though the most popular strategy, worried me particularly because of its interference with the core

I also found this article particularly useful in resolving my indecision. One aspect I had not considered with regard to a multiple domain site was the potential for path conflicts. I can certainly imagine a situation where both site1 and site2 have an /about path, and I cannot imagine an easy, maintainable way of getting round this within a multiple domain site without allowing drupal to create an ugly /about-0 path for site2. I find this distinctly unappealing, and it could cause some issues for existing paths.

I have always been quite reticent about using drupal's inbuilt multisite functionality to share a codebase between different sites (with different databases). For the purposes of updating etc it has often seemed simpler to me just to have separate codebases and manage shared code through version control, (because I can break a single site). In this handover situation, however, I think maybe a single codebase better communicates the absolute similarity of aspects of the different sites. As long as configuration is, as far as possible, captured in Features, there should be little confusion about the degree to which components and behaviours are shared between sites. The multisite codebase can easily be separated out into different sites later if required.

As a side-note, one advantage I had not previously considered for the multisite setup was the reduced amount of memory required to cache compiled PHP code (detailed here).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.