For one, the theme negotiator class can receive services from the container if we just name them in the service definition. Using this example, we can create more complex scenarios as well. Clearing the cache and hitting our new route should use the gianduja theme if one exists and is enabled. Additionally, we are also setting a priority for it so that it runs early on in the theme negotiation process.Īnd that is pretty much it. This is a normal definition of a service, except for the fact that we are applying the theme_negotiator tag to it to inform the relevant container compiler pass that we are talking about a theme negotiator instance. Use Drupal\Core\Theme\ThemeNegotiatorInterface Ĭlass ThemeNegotiator implements ThemeNegotiatorInterface Use Drupal\Core\Routing\RouteMatchInterface So let's create a simple class for this service inside the src/Theme folder (directory/namespace not so important): namespace Drupal\gianduja\Theme We need to implement a ThemeNegotiator that looks at the routes as they are requested and switches the theme if needed. However, just adding an option there won't actually do anything. The Controller implementation is outside the scope of this article. You can see our custom option at the bottom which indicates the theme this route should use to render its content in. Just a simple route for our first info page. _controller: '\Drupal\gianduja\Controller\GiandujaController::info' This is how a route using this option would look like: : We can call this option _custom_theme and its value can be the machine name of the theme we want to render with it. How would we go about implementing this in a custom module called Gianduja? The solutionįirst, we need a route option to distinguish these routes as needing a different theme. And we want to apply this theme to a few custom routes (the content rendered by the respective controllers is not so important for this article). Let's say we have a second theme on our site called gianduja since we just love the chocolate from Torino so much.
And like usual, I will illustrate the technique using a simple use case. And in this article I'm going to show you how it's done in Drupal 8. You could create a custom cache context for your use case, but it'd be the combination of the url.query_args:whitelabel (assuming ?whitelabel=foo is what you meant) and session cache contexts.Have you ever needed to render certain pages (or groups of pages) with a different theme than the default one configured for the site? I did. Cache contexts usually describe input from the request (such as the URL or parts thereof, the requestor's IP address, the associated user, the associated session, or even the matched route), but could also describe some global state such as which day of the week.
When data changes, the associated cache tag(s) are invalidated, causing the cached results to get invalidated and then recomputed.Ĭache contexts describe context dependencies, which means they describe variations. Thus I should invalidate the cache context.Ĭan I invalidate cache contexts? Or are there other options? I have thought of using a combination of both tags and contexts, but I am afraid the amount of combination will go through the roof.Ĭache tags describe data dependencies. However (probably on very low frequency) the parameters (name, logo, etc) could change. (This module allows the site name, logo and color scheme to be overridden initially based on a url token, but a session variable for subsequent pages.) So I thought such a whitelabel token would make up for an excellent cache context. The reason for asking this is because I am in the process of converting the white label module to Drupal 8.
Cache context drupal 8 how to#
Now I did find how to invalidate cache tags:Ĭache tags are invalidated using cache_tags.invalidator:invalidateTags() (or, when you cannot inject the cache_tags.invalidator service: Cache::invalidateTags()), which accepts a set of cache tags (string).īut I cannot find how to invalidate cache contexts. Examples for contexts are languages and themes, where the same set of entities need to be rendered differently. context (duh), so the exact same set of tags (entities) can exist under multiple circumstances with a different cache. This is mainly used for entities and configurations.Ĭache contexts provide. After reading both documentation pages, I have come to the following conclusions:Ī cache tag is used to tell Drupal 'what is in the cache', so the cache can be invalidated once something in the cache is updated. When updating my module from Drupal 7 to 8 I bumped into the concept of cache tags and cache contexts.
0 kommentar(er)
