Mar 27 2020
Mar 27

In the previous blog, “Know-How To Manage Multi-Site Configurations in Drupal 8” (link of the same), we learned about managing configurations across multiple sites and acquiring features from the common core platform. 

Today, the II part of this blog series will give you deep insights into the implementation of "Configuration Management across multiple sites".

But before moving ahead, let’s revisit the problem statement as discussed in Part 1-

The objective was to create one profile, i.e., “Core Platform” and accumulate all common features for easy distribution and sharing across multiple brands. 

Additionally, these features were made pluggable as well available for use to each brand in the future.

But there were two major challenges ahead. They were-


  1. There can be a massive amount of files to manage across 18 brands that may require more work upon them
  2. Moving configurations would require extensive care and testing at each step to avoid any loss of data, critical for the brands.

The Solution-

There are two approaches to solve the challenges. Each one is discussed below in detail-

A.  Separate Configuration Files for Each brand

This approach will ensure that all the configurations are kept separately for every brand, with each one having their own set of YAML configurations files. And while synching the configurations also, it can also be fetched for that specific brand only.

Although using this approach would result in:

  1. Increase in repo size as new features will be developed
  2. In case there is something that needs to be developed/deployed for multiple brands, then configuration files will have to be copied in every brand sync directory, thereby resulting in additional efforts of developers for copying files over multiple directories
  3. And, what if a new brand site is requested by the client? New directories will have to be created from scratch to manage configurations, leading to a bulkier repo.

Thus, we had to come up with a better approach that would result in maximum configuration files in common core platform directory and fewer files in brand-specific directories, besides common features across all brands).

Text and Drupal 8 logo in white backgroundSource: Medium

The new approach is-

B. Splitting Configurations for brands using Config Split Module -

In this approach, Config Split module is used to create a separate configuration sync directory for each brand where module settings let you select configurations from brand folders whenever Configuration Import is executed.

The Config Split module is used to split the configurations into a specific set required for a different environment or a different site. The aim is to fetch the configuration either from the split folder or from the core folder (it is specified in site’s

This approach will help you in moving all the common configurations to the Core sync directory.

Below mentioned are the steps that have been taken to achieve the objective-

 1. Exported all the brand-specific configurations and kept them under the brand-specific config sync directory using the config split module =>

For example, we have the site named "BPB News" and the folder for this under config directory is named as bbp. Here, we will export all our configurations and keep them under config/bbp directory. We did this for all the 18 brands.

Doing this will help us to get started with drush cex and Drush cim workflow on all brands.

 2. Using the Configuration Split module settings, as explained above, brand-specific split folders have been created:

Text written in white background

Also, the help text of the field says: "Configuration related to the "filtered" items below will be split from the main configuration and exported to this folder".

To export all the configurations to split directory we added " * " wildcard in the module configuration here :

Text and a dialog box on white backgroundSince our priority is to look for configuration items that will always be found in brand-specific folders, we can pick it up from the core as well, the main configuration folder.

You can test its working mechanism by deleting the split directory, ensuring that the configurations will be then fetched from the “Main”, the core directory.

So far, this is what we have been able to accomplish-

  • Brand-specific split folders to maintain brand-specific configurations
  • All the configurations are exported and kept in these brand-specific split folders

And this is what we aim to achieve-

  • The brand-specific folder should only contain the configurations that are specific to brands and should not contain configurations more than the "main", i.e., the "core" configurations directory.
  • Only then we will be able to get the ideal case of "Pushing all features to Core and keeping only brand-specific features in brands". This means the number of configuration files in the brand should be less than that of Core

 3. This is the testing stage, where we deploy all the changes to the Stage environment to check if configurations are now synced and no changes are displayed when we run "CIM" on any brands.

Finally, all sites were showing "No Changes in configuration" upon running the "CIM".

 4. To move forward, having all (Common configurations) configurations in Core and fewer configurations in site-specific configurations, and in brand split folders, we created and picked tasks in every sprint and performed this operation in several different tickets, such as :

  • Task 1: Moved all image style configurations in Core (Common) Directory.
  • Task 2: Moved all common view configuration files in Core (Common) Directory.
  • Task 3: Moved all common field configuration files in Core (Common) Directory.
  • Task 4: Moved all common Ad entity configuration files in Core (Common) Directory.

You can take a walkthrough of the Drupal configuration management from here-

[embedded content]

Working on a New Feature Request

When working on a new feature such as creating a new content type, all the configuration files related to "New Content-Type" creation will be picked up from the "Main" (Core) configuration directory. 

And in case if there is something that only a specific brand is requesting as explained in part I, then the configurations will be placed in the brand sync directory.

Usage of Configuration Ignore Module

We used Config ignore to add YAML configurations in ignore Settings. The idea here is to ignore synchronizing configurations that are changed regularly.

These changes might be any of the following-

  1. Changing form settings in the admin configuration forms. (In our case we call these settings, "Brand Level Configurations"). These can be custom admin forms provided by contributed modules
  2. In our case, the brand editors can change the placement of the blocks from the admin/structure/block page settings
  3. System Site Settings

These changes are made by the brand level editors and should be part of ignore module as when made to run, these changes would be reverted and lost during import.


Sharing our journey and findings of configuration management might not be the best-case scenario for everyone but it resolves our problem statement and facilitates us to develop features and manage configurations successfully. 

There is no denying the fact that there can be a scope of improvement here also. You can also share your findings or provide us with your inputs in the comment section below for a more efficient approach.

Need help with revamping your enterprise platform? Drop us a line and our experts will get in touch with you.

Mar 24 2020
Mar 24

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.

Colorful balls in various shelves

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!

Jan 06 2020
Jan 06

It is known that page load time is one of the important aspects of search engine result position. Site speed is what stands between the website and the potential user.

Caching therefore plays an essential role in optimizing websites to deliver high-performance. Not only does it help support faster load times than otherwise possible, but it also helps in reducing latency. The information can be stockpiled at every level right from the original server to intermediate proxies to the browser.

Drupal encompasses numerous tools for caching content that can work for your site exceptionally and it’s important to know what they are and what they do. This blog will elucidate the caching mechanism in Drupal 8.

Drupal 8 Caching Modules

By default, Drupal 8 comes with 2 modules for implementing caching-

  • Internal Page Caching:
The Internal Page Caching module when enabled, stores the complete page information even if the user visiting the site hasn’t logged in. Future anonymous visitors will then observe that the same content is loaded extremely fast since the page wasn’t put together from scratch. This module is useful for websites with a lot of unregistered users
  • Internal Dynamic Page Cache:

The Internal Dynamic Page Cache module is designed to cache small sections of each page for all users whether they are logged in or not. Whenever the page content is requested by the same or different user, the module can pull in those individual parts to speed up the building of the page on the fly.

Understanding Caching At Different Layers

Caching in Drupal takes place at three separate levels: application, component, and page. Given below is the detailed description of each-

  • Application-level Caching

Application-level caching is in-built in Drupal. However, you won’t see it in action until you scrutinize Drupal’s internal code. It is active by default and won’t even show older, cached pages.

The application-level caching in Drupal ensures that the cached pages are separately stored from the site content (which goes into the database). You can’t set this up, except for guiding Drupal where to save cached pages explicitly. 

Drupal stores its external and internal data structures efficiently to enhance repeated users’ access when performing application-level caching. This isn’t the information that a site visitor sees in itself but forms a critical factor in constructing any page. The only level of refinements that can be made at this level is improving where this cached information is stored, like using Memcached instead of the database.

  • Component-level Caching

Component-level caching works on front-end components such as blocks, panels, and views. For example, you might own a website having dynamic content but a single block remains constant. In fact, you may have the same block widely scattered across dozens of pages. Caching it can deliver improved performances significantly.

Though component-level caching is generally disabled by default, however, you can make it active with some simple configuration changes. You can initiate with identifying blocks, panels, and views on your site that remains the same across to later cache them strenuously. You will notice a strong speedup for authenticated users.

  • Page-level Caching

As the name suggests, this page-level caching caches, stores, and delivers the entire page to the user. One of the most effective types of caching,  it shoes static HTML pages to users to improve site performance almost immeasurably.

Page-level caching gives you enough space to customize where you can use any number of caching servers, including Varnish, or CDNs like CloudFlare to deliver cached pages from servers close to the users’ location. 

CDNs help you in bringing your site closer to your users. However, it only works for anonymous users by default. Fortunately, this drives huge traffic to any website.

A typical Drupal application comprises of all the layers mentioned above. However, to better understand the flow and learn how to debug a caching issue, a flowchart is given to illustrate how content is cached at different layers-

Flowchart of how caching works in Drupal 8Learn more about caching from here-

[embedded content]

Cacheability Metadata in Drupal 8. What is it?

Cacheability metadata is used to describe the thing which is rendered with respect to its dynamism. Сaching properties could be applied to any object and one can easily change the default cache settings of these three properties-

  1. Cache Tags  
  2. Cache Contexts  
  3. Cache Max-Age
  • Cache Tags: 

Tags are used to nullify cache entries when something on the site undergoes modification. (nullifying or invalidating means that the cache entry won’t get used, and will be reconstructed the next time that piece of content is rendered). Drupal comprises multiple cache tags to explicate all sorts of different scenarios from individual nodes and blocks, to site configuration settings, and menus. 

For example, the cache tag ‘node:5’ gets invalidated any time the Drupal content node with ID 5 gets modified.

So, whenever content gets cached which depends on something related to node 5,  the cache entry keeps track of that tag; then, saving the node causes that cache entry to get invalidated. This implies that any time you save something in Drupal, a relevant tag gets invalidated.

The tag for the same will look like this-

Syntax : “node:5” 

node_list: List cache tags for node entities

  • Cache Contexts: 

Contexts are quite different from tags. Cache contexts are stored alongside cache entries and are designed to let content vary depending on what circumstances or situation it is showcased in.

For instance, you have a site with users of several different roles, and one block on the site is meant to show content differently depending on what roles the user seeing it has. This can’t be implemented through cache tags alone. However, it won’t be a good idea to leave the block completely uncached, instead, it can have the “user permissions” context applied to it. This way, the block can be cached multiple times- specifically one time for each combination of roles that the users see the block have. This way, an administrator can see something different from an editor who will see something different from a user who has both roles.

Commands shown in for caching tags

  • Cache Max-age:

Cache max-age is the last step to handle cache invalidation. You have to simply set the time on how long the content should be cached for. This can vary from 0 seconds (to not cache content at all) to as long as you want. 

Presuming that all of the tags and contexts being used are working as intended, this can be put to indefinite (default state in Drupal) since those can cover most scenarios where cached content might need to be created.

Given this, there is still no mechanism that notifies your Drupal site about the change in content, and therefore, no-cache tags can be invalidated and no context is helpful (as the content doesn’t vary by the situations in which it is displayed).

However, if you set a max-age of 3600 on the page, then it will cache its content for up to one hour before automatically invalidating, at which point the next person who views the page would get a brand-new updated version (fresh with new content from the remote service) which would then get cached for another hour. This way, you can leverage all the benefits of caching without causing your site to stop updating itself with content from the remote service. 

Summing Up-

Caching lets you retrieve data instantly without having to request it from the source. Given that, it makes up a significant part of website speed optimization. If you want to ease surfing experience for your users on the site, then enable the cache for the same. Drupal 8 has enhanced its caching capabilities considerably.

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web