Panshul khurana

Panshul khurana

Recent Posts

The Fundamentals of Caching in Drupal 8

Posted by Panshul khurana on Jan 6, 2020 7:10:44 PM

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-


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.

Topics: Drupal, Planet Drupal, User Experience and User Interface, Drupal 8

How to display a custom form mode in Drupal 8?

Posted by Panshul khurana on Aug 16, 2018 12:08:00 PM
“ How you look at it is pretty much how you'll see it ! "

Recently, in a project, I came across a problem statement where I was supposed to display a Node Form to an authenticated user with access to edit only limited set of fields, in a way similar to maintaining a Linkedin profile.

The ideal solution is to create a separate form mode with the ability to access only a limited number of fields and keeping all other fields disabled from displaying in the form itself .

In my mind, this looked pretty easy to implement; but I was stuck at a point where I had to use this “Custom Form Mode”. This is when I realised, Drupal 8 core does not provide any interface or help to make use of the “Custom Form Mode”. We have to programmatically call the custom form mode and display it to the type of user intended.

Also I came across this module Form Mode Control which does provide help in terms of managing permissions and form modes through an admin interface, but if you want to avoid installing another contributed module for a small implementation(similar to our case) which does not involve managing multiple roles / users and also does not require providing a manageable admin interface then this simple solution is a way to go !

Through this post, we’ll look into the following :

  • Creation of a Custom form Mode
  • Use of the form mode to display Node form as a block to an authenticated user.

Before we move ahead with actual implementation, first let’s understand the basics

What is a Form Mode and how is it different from View Mode ?

According to the Drupal documentation here

  • Form modes are a way to create different field configurations with the same content entity bundle.
  • Form modes allow for multiple sets of field widget orderings and customizations, just as view modes allow for different orderings and customization of field formatters.
  • In addition to form modes, form operations allow for defining which classes should be used for forms like a node delete form.


  • View modes exist to allow Drupal site building tools like Entity Reference fields to request a given entity be rendered in a certain way.

With this background, let’s learn how to do this !

Create a Form Mode :

  • First step is to create a separate Form mode at : /admin/structure/display-modes, This page will provide 2 options , Form Mode and View Mode. Since here we are going to create a form mode, we will select “Form Mode” .
  • In the next step, we will get an option to select which form should be created.. Ex. Content, Taxonomy Term, Contact Form. In our case let’s select Content. And provide the name of the Form mode as required. [Refer the Screenshot Attached]create a FormModes drupal8
  • After creating a form mode , let’s use it for our content type. In my case , I have created a custom content type by the name “Agency” and added a few fields to it. To use the custom form mode created, head towards /admin/structure/types/manage/agency/form-display and at the bottom of the page you should be able to see the “Custom Display Settings” tab, here you should be able to see the your custom form mode in the list. Simply check and enable this Form Display [Refer the Screenshot Attached]CustomDisplaySettings
  • In this form mode, you can order or enable/disable the fields that you want to display.

Create a Module and Set Form Class :

    • The next step is to create a custom Module and set Form Class as follows: [Refer the code snipped below]
         * Implements hook_entity_type_build().
        function display_custom_form_mode_entity_type_build(array &$entity_types) {
          $entity_types['node']->setFormClass('company_form_mode', 'Drupal\node\NodeForm');

Create a Block and Call the Node Form :

    • Now let’s create a custom Block and Call the Node Form as follows : [Refer the code snipped below].
         * Implements \Drupal\block\BlockBase::build().
        public function build() {
          $build = array();
          $nids = $this->getNodeFromCurrentUserProfile();
          //Display Node Form.
          if (!empty($nids)) {
            $node_form = Node::load($nids);
            $build['form'] = $this->entityFormBuilder->getForm($node_form, 'company_form_mode');

         return $build;

        public static function getNodeFromCurrentUserProfile() {
          $nids = '';

          // Fetch Email ID
          $current = \Drupal::currentUser();
          if ($current->id()) {
            $account = \Drupal\user\Entity\User::load($current->id());
            if (!empty($account)) {
              $email =  $account->getEmail();

          //Fetch Company Id.
          if (!empty($email)) {
            $query = \Drupal::database()->select('node__field_mail', 'nce');
            $query = $query->fields('nce', array('entity_id'));
            $query = $query->condition('nce.bundle
              ', 'agency');
            $query = $query->condition('nce.field_mail_value
              ', $email);
            $nids = $query->execute()->fetchField();

          return $nids;
  • In the code snipped above, I have created a link between Current Drupal User account and Company Content by the field “Mail”. Further, the Company Node is fetched for a specific User, in order to display different Content Forms to different users.

Create a Page and Place the Block :

  • Next ,place the block on a page and now you should be able to see the Custom Node Form as follows: [Refer the Screenshot Attached].Company_profile_form

With this, we have now successfully created the Custom Form Mode and used it to display it as a Block to an authenticated user.We have come a long way in Drupal 8 and now it’s high time to get some implementations up and running as a part of Drupal Core as things like these are an essential component of site Building. If it was difficult to understand in terms of steps, please refer the Youtube video Link below to get some more clarity on the steps :


Also you can follow this github link to get the code and get the Custom Form Mode implementation up and running :

Thank You.

Topics: Drupal, Planet Drupal, User Experience and User Interface

Drupal website personalization with SharpSpring

Posted by Panshul khurana on Nov 8, 2016 1:23:00 PM

What is Personalization ?

When you go to a cafe and order coffee, the barista asks you how you want it. Your answer depends upon the choices made available to you. Based on your preferences/likes/dislikes, the barista makes the coffee.

If you are a regular visitor, and have interacted with the barista several times, then they might not even need to ask what you like. They would know what you want, the moment you walk through the door.

Website personalization is very similar to your choice of coffee. Basically, it's content displayed to you on a website, based upon your characteristics and user profile. In other words, it’s tailor-made to your preferences.

Why do we need personalization ?

Why do we need personalization ?

Website personalization is the key to effective content marketing. It’s an important implementation for websites, that allows them to customize and display different content to different users, based upon their behaviour on the site. It is one of the best tools to determine what a user is interested in, and according to the data collected, make improvements in the UI or the content available on the site. Most marketers agree that content marketing makes up an important piece of their advertising strategy.

How can we achieve website personalization in Drupal ?

There are several tools and modules available to achieve content personalization on a website:

  • Personalization: Provides configuration to add implicit and explicit personalization to Drupal websites based upon geo-location and taxonomies.
  • SharpSpring and SharpSpring Personalize: These modules can be used to add SharpSpring tracking to website pages. They can also personalize content on the website using data returned from SharpSpring on page-visits, or information about the user/lead visiting the page.
  • Acquia Lift: An Acquia solution that unifies content and customer data from multiple sources to deliver data-driven, personalized experiences across any channel or device.

With the introduction of BigPipe caching, content personalization for Drupal site also got a whole lot faster.

In this blog, let's focus on the SharpSpring module to achieve content personalization of a single block. Our purpose is to display personalized content to different users/leads according to their profile present on SharpSpring.

What is SharpSpring ?

SharpSpring is a marketing automation platform that combines site analytics and lead generation in one Platform as a Service. It tracks user activities on website and provides relevant data to the admin.  This allows them to create more powerful automation rules, that can send dynamic content to the lead, and target leads based upon their interests.

Workflow of the implementation

Workflow of the implementation

  • The flow starts with an email that is sent from SharpSpring web portal to the targeted lead, with the URL of the website whose personalized content is to be displayed. Here we are making an assumption that the lead data is present on SharpSpring web portal.
  • The lead receives an email and clicks on the URL present in the mail. They are then redirected to the Drupal website.
  • As soon as the lead clicks on the URL, the SharpSpring module installed on the Drupal portal makes an API call back to the SharpSpring portal. This API is responsible for fetching lead details from SharpSpring. The amount of data that is returned depends upon the data present in SharpSpring.
  • SharpSpring then recognizes the person who clicked on the link as a lead (if the profile is created on SharpSpring) and returns all the data present on the portal related to that lead in a form of a JSON object as shown below :                                                                                                                                                                  SharpSprin
  • In our Drupal portal, we are then capturing lead details in the form of a cookie, and reading the data from the cookie.

Also, we have our content tagged with a taxonomy term. In our case, let’s take an example of the taxonomy term “Job Title”. In this case the title that will be captured is “Intern”. Now, only the content on the site tagged with the term 'intern' will be displayed to the lead, here named as “Panshul Khurana”. In case for a different lead where Title is “Developer”, only the content tagged with the term “Developer” will be displayed to that specific lead.

Hence, according to the lead details captured from the SharpSpring portal, the content on the site is being personalized for that specific lead.

Pre-Requisites in the current implementation

  • Lead must have a profile in SharpSpring
  • Lead must click the promotional link at least once to trigger content personalization

There can be multiple ways to achieve website personalization. The idea is to automate the system or develop a system which is not dependent on a third party tool and have a system that captures user details and displays the personalized content at any level, be it block level, content level, or even a UI based personalization.

After all, it is all about providing a customer his favourite coffee, brewed exactly how he likes it. ;)

And if you have already implemented some basic website/content personalization, we have a few forecasts that you might find useful.

Topics: Drupal, Personalization


Write to us

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms Of Service apply. By submitting this form, you agree to our Privacy Policy.

See how our uniquely collaborative work style, can help you redesign your business.

Contact us