Here is an example of inspecting the cache of the breadcrumb element on a page of content. Well, actually it means that the auto_placeholder_conditions do not match the auto_placeholder_conditions of the page, but this essentially means that the cache is not validated for the context of that page request.īy hovering over each of the letters within the page you can get more information about what the cache is doing at that point in the page. If the letter C or N is shown in red this means that the cache of that element is not being cached correctly. Which means that the cache "tags", "contexts" and/or "max-age" settings are being used to control the cache of this item. Meaning that the cache is being generated through the lazy builder interfaces. This essentially means that the item is cached in a separate cache bucket from the central cache system, but is still being cached in some way. The letters have important meaning with regards to the current state of the cache. The most important part of this information are the letters placed around the page. This does look a bit messy, but it is trying to convey a lot of information all at once. Here is this site with the cache review module turned on. Information regarding the cache is injected into every element on the page along with a synopsis of the overall cache at the top of the page. This essentially means that the entire front end of your site will contain lots of information about what the cache is doing. Using Cache ReviewĪfter enabling this module it will automatically add cache information to non-administration pages. The module has no configuration or setup, so it is ready to use once installed. You can do this through the administration interface or via Drush using the following command. With the module in the codebase it's just a case of enabling it. This is installed as a dev dependency just in case the change to composer was committed to git. composer require -dev drupal/cache_review
With that done you can require the Cache Review module like this.
#Drupal 9 cache contexts install
This module is quite rightly labelled as a development module and you need to allow composer to install a module in this state. Installing Cache Reviewīefore you can add the Cache Review module to your codebase you need to set the "minimum-stability" setting in your composer.json file to "dev".
It's never to be used in production as it does create a lot of output on the page (even for anonymous users) but it is a very useful tool in getting to grips with what your cache is doing. The module has been designed to decorate the outgoing page request and add lots of cache information to the page. This is where the Cache Review module comes in. Performance analysis will tell you where the most database reads are coming from, which is usually a good indication of poorly cached content.
The best place to start is by turning on debugging headers and looking to see what sort of cache tags are being generated. Solving these problems is very important but can be a time consuming process. If one element on your page is not caching correctly then this can cause the whole page (and sometimes the entire site) to not be cached properly. Tracking down issues in the cache system can be a complex task. Each part of this page can be cached in different ways and all of this information bubbles up to the aggregate page cache. You might have a page that displays content from a node and contains a few blocks to show menus, search forms, share links, and similar. The results of the render can be stored in a cache and served much faster than having to recreate them again. Having a cache means that Drupal doesn't need to go back to the database and ask all the elements of the page to re-render everything for every page request. Drupal has a robust and dynamic cache system that allows complex pages to have different parts of it cached in different ways.
0 kommentar(er)
