If you implement any form of access or alter existing access hooks, ensure you return one of these:
CACHE CONTEXT DRUPAL 8 CODE
A random sort in views or code will cause the page to be not cacheable.Īll access-checking logic must now return AccessResultInterface objects, which allows for cacheability metadata. */įunction mymodule_preprocess_block(&$variables) Īvoid random sort. ** * Implements hook_preprocess_block(). That will cause Drupal to send the corresponding X-Drupal-Cache-Tags and X-Drupal-Cache-Contexts headers to cache tags and cache contexts. For this to take effect, the container must be rebuilt. Cache contexts = (request) context dependenciesĬache contexts are analogous to HTTP's Vary header.You can debug cacheable responses by setting the _cacheability_headers parameter to true in your services.yml. Why?Ĭache contexts provide a declarative way to create context-dependent variations of something that needs to be cached. correct usage of this cache improve the site preformence greatly. Some expensive-to-calculate data depends on the active theme: different results for different themes.By making it declarative, code that creates caches becomes easier to read, and the same logic doesn't need to be repeated in every place where the same context variations are necessary. Drupal 8 shiped with a powerfull cache API able to set cache according to a context. When creating a render array that shows a personalized message, the render array varies per user.Then you'd vary by the theme cache context. Generally: when some expensive-to-calculate information varies by some environment context: vary by a cache context.Ī cache context is a string that refers to one of the available cache context services (see below).Ĭache contexts are passed around in sets (order doesn't matter) of strings, so they are typehinted to string.Then you'd vary (the render array) by the user cache context. Adding context (such as language) will create a new cache for each context (ie - separate cache for each language) Max-age: How long the cache should live for. If there are on cache contexts, then only one version of the cache is cached for all users. They're sets because a single cache item can depend on (vary by) many cache contexts. Cache contexts: Describe variations of a cache. Typically, cache contexts are derived from the request context (i.e., from the Request) object. Most of the environment for a web application is derived from the request context. After all, HTTP responses are generated in large part depending on the properties of the HTTP requests that triggered them.īut, this doesn't mean cache contexts have to originate from the request - they could also depend on deployed code, e.g., a deployment_id cache context. Second, cache contexts are hierarchical in nature. Everybody uses cache, but not everybody is able to manage it. Here is how that is done for the system branding. Next, you add a custom class to the block. You can get the block ID in the advanced section of the view. First, you need to get the config key for the view block. The clearest example: when varying something per user, it's pointless to also vary that per permissions (i.e., the set of permissions that a user has), because per-user is already more granular. Cache is the important part of a development process. You can add a backend class for the block, then add a cache context on language to that block.
A user has a set of permissions, so per-user caching implies per-permissions caching. Now for the most interesting aspect: if one part of the page is varied per user and another per permissions, then Drupal needs to be smart enough to make the combination of the two: only vary per user. a plurally named cache context indicates a parameter may be specified to use: append a colon, then specify the desired parameter (when no parameter is specified, all possible parameters are captured, e.g., all query arguments)ĭrupal core ships with the following hierarchy of cache contexts: cookies.That is where Drupal can exploit the hierarchy information to not create unnecessary variations.
Protocol_version // Available in 8.9.x or higher. Note: To use the _front cache context in prior branches/releases, see the change record.Įverywhere cache contexts are used, that entire hierarchy is listed, which has 3 benefits: is_front // Available in 8.3.x or higher. Context Cache is module which lets you control caching and expiration through Context. no ambiguity: it's clear what parent cache context is based on wherever it is used.Cache tags and contexts gives Drupal 8 the smarts to identify sections from. Comparing (and folding) cache contexts becomes simpler: if both a.b.c and a.b are present, it's obvious that a.b encompasses a.b.c, and thus it's clear why the a.b.c can be omitted, why it can be "folded" into the parent. This module demonstrates the impact using the Cache API in Drupal 8 can have.
0 kommentar(er)
