Managing Multi-Site Configurations in Drupal 8 Part I

Configuration management is one of the most prominent features of Drupal 8. You can easily import and export configurations using YAML files and also store them in the “config” table of the database. 

Given this, it has become a cakewalk now to pass commands in Drush and follow the steps required to export configurations from one environment and import it to another, thereby making it easier to manage them in code-base using the version-control system.

However, things turn out complicated when it comes to managing multiple site configurations that employ a “single” platform for streamlining common features across various brands.

For instance, there is information in the article that all brands want to use on their respective sites. The twist is that each brand wants to use different sets of fields and display pattern to showcase it on their site.

Thus,  the problem of this solution is to create one profile, “Core Platform” and place all common features for easy distribution and sharing across multiple brands. Further, these features should be pluggable as well available for each brand to use in the future.

This blog series (Part I & II) will help you understand the development process and maintenance of -

1. common configuration across multiple sites
2. Different configurations as per brands’ requirements
3. Configurations as per the environment, and
4. Usage of configuration Split Module and Configuration ignore

Please note that if configuration management is a new business for you, it’s highly recommended to go through the Drupal documentation first to acquaint yourself with configuration export and import commands.

Moving forward, let’s consider two cases to determine whether a feature should be brand specific or need to be pushed as part of a Core platform to become available for multiple brands. 

Case 1 :

Multiple brands have requested to introduce a new content type, “companies on the move” section, which lets anonymous users submit their entries in the same and complete the process by going through a checkout process. This will display users’ submitted profile on /company-on-the-move listing page.

So, these are the following questions that crop up, considering the case I:

1. Which multiple brands have requested this new content type?
2. Is there anything specific that brands need to be configured or displayed differently for them?
3. Are the display items (fields) on /company-on-the-move listing page the same across all brands?

Now, if answers to the above questions involve “brand A, B, C, D, and Nothing”, i.e., nothing specific needs to be developed and displayed for any brand, then it is an indication for core platform features.

Besides, these features in the core can be employed by any brand, anytime in the future.

Case 2 :

Brand A and B want to add a specific new field for their editors to company content type, which would be accessible for them only. In this case, we’ll have the following info available across all brands:

• Company Content type with all the required fields.

It is obvious that only Brand A & B require this feature, so it will be known as “Brand Specific”.

It can be achieved through the following steps-

1. Create the requested fields in the "Common Core" platform and push it to all brands and write hook_form_alter() to hide that specific field for all other brands except Brand A and Brand B.
2. Create the requested field just for Brand A and Brand B and push the configuration for these 2 brands.

Since our objective is to manage configurations across multiple brands, we’ll take forward the 2nd approach from here onwards.

Learn more about building a Drupal multisite from here-

Development Process 

With a clear understanding of the features’ availability and unavailability for multiple brands, developers can find it easy to jump onto the implementation part.

Case 1 :

1. Create the new content type on our "Core platform" local site and place the configurations exported (field storage, field, view, panel page for company listing page, form display, view display) under the Core configuration sync folder.
2. Upon successful code merge and deployment, run CIM on all brands to get the new content type across all brands.

Case 2:

1. Create fields for just Brand A and Brand B
2. Export and keep the field.field..... and core.entity_form_display... YAML configuration file in brand-specific configuration sync folders.
3. On deployment, run drush cim --uri and drush cim --uri=brand_b to import the required configuration files for just these 2 brands.
4. In this case, other brands will continue using the form display configuration file from Core (the main) configuration sync folder.

Summing up-

Thus, you can decide and develop Core/ brand-specific features hassle-free by following the above-mentioned steps. 

And to learn more about the development process and implementation methods, stay tuned for the next part of the blog, “Configuration Management in Action”.

Keep Coding!