I have a multi-site setup based on Domain Access. One Drupal installation serves three sites. The three sites share the same database (because some content is published on multiple domains) and also share the same code base. The sharing of the code base is becoming a problem at this point. We have created some custom modules for the sites, for example a custom module to alter the Apache SOLR search results (and other things like facets, item-lists, and so on). At first this didn't give any problems because only one of the three sites had SOLR enabled, but now the customer wants to enable SOLR search on the other domain as well.

The problem that pops-up here is the fact that the custom module which implements hooks for SOLR is used/called on both domains. So every modification for SOLR on domain 'a' is also done on domain 'b', this is a problem on itself but this is fixable by adding an if-statement to check on which domain the user currently is. This isn't a really neat solution but it can work if it is the only way. A bigger problem are the 'hook_theme' implementations. We used different hook_theme functions to override/alter the search results (and facets, and so on) on domain A and now those modification are also used on domain B, this is something we don't want. I want the hook_theme implementations to only run on a specific domain. Just adding an if-statement to them isn't going to work because at that point there is no domain available (after clearing cache and such).

Is there a way to enable a module only on a specific domain, such that custom module 'CM' is only used on domain A and not on domain B? Would this fix the problem with the theme registry? And if it isn't possible, is it possible to register theme hook only for a specific domain?

Thanks in advance!

Comments

Robert_W’s picture

Title: Load / active module per domain » Load / activate module per domain

Title was stupid.

agentrickard’s picture

This is a problem we have deliberately not tried to solve due to the sheer amount of confusion/security issues it may create.

The theme issue could be handled by using subthemes and domain_theme. But domain-specific logic would need to be handled like you're doing now.

Shyamala’s picture

Reviewing a large Domain access site with multiple domains. Functionality common to a large extent across domains. The variants of functionality mainly around user registration workflow, profile fields, e-commerce functionality (around taxation rules, etc.). The main problem faced today is the maintainability of the code when the development team updates domain specific changes. Identifying to see the best approach to prevent this.

Summarizing below best practice for better management of Domain access sites.

A. Use the below modules as much as possible to segregate domain specific functionality:

  1. Domain Conf/ Domain Variable as applicable
  2. Domain Rules
  3. Domain tokens

B. To facilitate better maintenance as much as possible:

  1. Move functionality using features (supports domain access)
  2. Use Drush
  3. Use one of the 2 methods recommended at: https://www.drupal.org/node/1096988 to manage development workflow with the same codebase.

C. If you need to write domain specific code, ensure to add the domain to which it is applicable using a "if condition".

As regards to point C want to check if there is an alternate approach where in we can include inc files where the same hook is implemented and included separately for the domains. I understand this will be a problem from a Drupal cache perspective, to resolve this use Domain prefix module to create domain specific prefixes for the drupal cache tables. From the discussion on this thread, this is clearly not a recommended option - looking for more details on why?

agentrickard’s picture

Status: Active » Closed (works as designed)