Drupal 8’s Domain Access module provides a tool to run a group of sites from one instance. It’s very useful when you are planning to have few similar sets of sites with different content.
I did some assessment of the Domain Access in Drupal 8 and decided to put together a quick guide to help decide when to use it, and when not to use it.
Pros and Cons of using Domain Access in Drupal 8
- Business users can effortlessly manage all content from one platform
- Easy to publish and share the same content on multiple sites or all sites
- Reduced hardware support requirement as you use the same database and code base. The server configuration however will vary on the traffic.
- Authenticated users on any one site of DP can access other sites as well, and it’s easier to manage all users from one place.
Impacts Performance: Domain module filters the content into
- Domain specific content
- Content which needs to be displayed in all the URLs
If authenticated user are logged-in, then all the blocks get counted and only domain specific blocks render. So if we use domain specific blocks, it might lead to reduced performance.
Downtime: Any issue on one site will lead the downtime for all other sites.
Development Efforts: With every functionality that you add, the domain functionality needs to be extended to make sure that the functionality get loaded when the site is rendered.
Theming Challenges: Rendering different themes on different sites is a challenge. If your requirement is to render individual themes, and if some/most parts of it are not reusable, then you are faced with huge problems.
User Experience: If the content editor has access to publish the content on multiple domains, there is a possibility that they enter the wrong content on the wrong domain, leading to a bad user experience.
Increased QA Efforts: Any changes to the codebase or adding new feature on any site will require regression testing for all the sites.
Site Specific Configurations: If there are certain requirements that need to be implemented on a specific site, that might need extra effort in development and management. e.g if Google Analytics needs to be configured domain specific from a single database, we need to customize the added GA (just an example) token key to the specific site.
Things to keep in mind to use Domain Access in Drupal 8
So you have weighed the pros and cons, and decided to go ahead and use the Domain Access module. What next?
Here are a few key things that will be helpful in ensuring a faster and scalable site:
- Theme Reusability: Try to reuse the regions and similar html structure/layout.
- JS/CSS : Try using common JS/CSS files and make the code more generic.
If you are going to create multiple sites in a single instance, then opt for dedicated hosting. Try to keep the db server separate from the web server.
User will authenticated using single sign on. Stopping it will lead the duplication in the database. If users are registered from one site, they won’t be able to register from the other site. So we need to give a clear message so that users can use login just once.
A few other things we recommend, to help reduce the performance headaches:
Redis: Irrespective of how much traffic is expected on the site, we can use Redis for authenticated cache as well as anonymous cache. This works on the LERM algorithm which might be helpful here.
Varnish (Optional): As a reverse proxy, we can use varnish with Drupal 8. It will help to reduce the downtime of the site in case there is any issue. (Note - we can discuss and then we can move Varnish in or out)
CDN: For assets/security we can use CDN to reduce the web server load with CORS implemented. All the media/JS/CSS/Font will go to CDN server.
So that was my assessment of Domain Access in Drupal 8. If you are well versed with using Drupal 8, hope this helps you take an informed decision on whether to opt for it or not.
If you are new to Drupal 8, and want to quickly the get hang of it along with the rest of your team, you should definitely take a look at our Drupal 8 Training program.