#D8 cacheability

Will try to find time next week to test this. If someone wants to have a crack at this in the meantime, go ahead.

Wonder if the IS could get some love. Using the standard template please

Good to see the tests still pass but believe will still need test coverage

Thanks.

They're tagged services, which I think means they fall under this rule of not being covered by BC.
https://www.drupal.org/about/core/policies/core-change-policies/bc-polic... →

This has broken several contrib modules that inherit from PathBasedBreadcrumbBuilder --

- 🐛 BusinessRulesBreadcrumb must be compatible with PathBasedBreadcrumbBuilder on Drupal 10.4.0 and above Active
- 🐛 Fatal error: Declaration of Drupal\entity_ui\Breadcrumb\AdminBreadcrumbBuilder::applies Active

Meh added it to the baseline. The alternative was asinine:

    if ($this->rendererConfig['debug'] === TRUE) {
      $render_start = microtime(TRUE);
    }

    // Had to become (also further down):
    $debug_mode = $this->rendererConfig['debug'];
    if ($debug_mode) {
      $render_start = microtime(TRUE);
    }

To hell with that :)

Why is phpstan choking on this on an unrelated variable that it should know how to inspect.

Needs tests and we need to update https://www.drupal.org/docs/drupal-apis/render-api/auto-placeholdering#s... →

Also we should check if we want to load defaults for pre_render and post_render. But there we need to also check if defaults were already loaded and someone changed the type.

Opened 📌 Refactor the render context stack to avoid a static property Active .

I think #4 is very similar to 📌 Entity lazy multiple front loading Active - in purpose if not implementation, and also 📌 Add PHP Fibers support to BigPipe RTBC .

That leaves #5.

#2 is definitely still relevant, render context is currently tracked in a static property, although we should open a dedicated issue for it.

Is this issue still needed?

Re #21: Fair.

Maybe we need a way to create two (or more) groups of routes. One group is accessed by browsers, others by special clients. Then apply different sets of rules for request processing, content/language negotiation, authentication and caching to each of them.

However, page cache is only effective if it runs before request routing. So maybe the matching needs to happen on a path prefix.

Using the header and vary on that is very dangerous for cache purposes. It will make very very many variations, which results in bad caching and performance. Not to mention possible memroy issues in caches or high cache trashing.

While this is true for a web-based environment, it is not true for JSON:API.
Quoting @GabeSullice from https://www.drupal.org/project/drupal/issues/2794431#comment-12806367 🌱 [META] Formalize translations support Needs work

However, JSON API doesn't need to be very concerned about that because JSON API requests are not typically made directly via a browser. Instead, they're most frequently made via JavaScript or some other system where the Accept-Language header can be tightly controlled by a developer.