ThemeKey 8.x Brainstorming / Roadmap

Updated issue summary.

updated

added blocker

https://drupal.org/node/2150863

'theme callback' and hook_custom_theme() got replaced by theme negotiators
https://drupal.org/node/2158619

We need to figure out how to deal with cache tags and cache keys. Do we need to set or invalidate something when a rule matches, for example based on the user agent?
How do we deal with #lazy_builders, placeholders and big pipe?
We have to ensure that a lazy builder uses the same theme that was used to generate the page that contains the placeholder.

Hi Markus,

Sorry for the delay.

today we brainstormed about the D8 port of ThemeKey:
https://www.drupal.org/project/themekey
Basically it triggers a selection of a theme based on a rule chain.

Okay :) Interesting. This screams ‘cache contexts’, but more about that later.

Now we wonder how these lazy builder stuff and big pipe will deal with that?

If ThemeKey decides to use a theme render a page it will consist of various
placeholders, right?

Big pipe will then replace these placeholders by calling the corresponding
lazy builder callback url. For this call we have to ensure to things:
1. The theme negotiator of ThemeKey must be bypassed. How can we identify
these requests?
2. Another theme negotiator in core must ensure that the same theme is used
again as was used to originally render the page. Does such a theme negotiator
already exist in core?

BigPipe works in the *same* request. Given that there are not multiple requests going on, ThemeKey’s negotiated theme will continue to be active.

It’s only once you start using ESI that this becomes potentially tricky, depending on how ESI is implemented. But let’s address that in the future :)

In addition I wonder if and how we have to manually have to deal with cache
keys or tags when ThemeKey selects a theme, for example based the day of the
week. In D7 we implemented hook_cron() to figure out if the rule chain
consists of "time-based" properties and cleared the page cache if such a rule
toggles to a new result.

If a theme is selected based on part of the request context (path, language, IP address, country …), then it needs to set a matching cache context: https://www.drupal.org/developing/api/8/cache/contexts.

If a theme is selected based purely on the day of the week, then it needs to set a matching max-age: https://www.drupal.org/developing/api/8/cache/max-age. (Assuming this is determined from the POV of the server, not from the user; if it also takes into account the user’s timezone, then you’ll also need the ‘timezone’ cache context.)

If the “rule chain” is modified and you want changes to take effect immediately, you will also need to associate the cache tag for the config object that contains this rule chain.

In other words: it looks like you’ll need cache contexts, max-age and tags: i.e. all bits of cacheability metadata.

The question is: *where* to associate this? All your logic must run in a ThemeNegotiatorInterface. So that would also be the natural place to apply the corresponding cacheability metadata to the response, right? Except, at that time, there’s no Response object yet!
For cases like this, we use request attributes. There is a very similar example in core: access checking performed during routing. An access check result also has cacheability metadata. We need that to be associated with the Response object, but it doesn’t exist yet. So what the AccesssAwareRouter does is store an “_access_result” attribute on the request that contains the access result object (which includes cacheability metadata). Then there is a RouteAccessResponseSubscriber that applies the cacheability metadata to the Response object when the response is ready.
The final challenge is that theme negotiators do not get the Request object by default. But you can just inject the RequestStack and get the current request, then modify it. An example of that can be found in the BatchNegotiator theme negotiator.

I think/hope this answers all your questions :)

Wim

We still wait for a sponsor or to be involved in a project that will use ThemeKey. It's too much work to do it as a hobby.

@amarincolas see #3213791: Co-maintaining this module?

ThemeKey rules and properties should be migrated to Drupal's condition system that was introduced in Drupal 8. There's already a tiny theme negotiator that does the theme switching based on conditions: Theme Switcher.

We decided to leverage Theme Switcher as new "engine" for Drupal 8 and 9.

So the current plan is to keep Theme Switcher small and to use ThemeKey as an extension to provide additional conditions if required.

Like in the past it would be better if other contrib modules provide their own conditions, just like we encouraged them to provide their own ThemeKey properties. But we still have the freedom to do some stuff here.

Any help in migrating the rules and properties to conditions is welcome!

Having a such a list would be good. I'm sure that they have to be implemented in different ways. Help is welcome, even for creating the issues.