Quantcast
Channel: Issues for Drupal core
Viewing all articles
Browse latest Browse all 294680

CacheableInterface only has a getCacheKeys() method, no getCacheContexts(), leads to awkward implementations

$
0
0

Problem/Motivation

#2158003: Remove Block Cache API in favor of blocks returning #cache with cache tags introduced the concept of cache contexts. #2167039: Regression: page cache tags broken, also: some routes incorrectly use _controller -> No page object in template variables -> Fatal in seven_preprocess_page() introduced CacheableInterface.

CacheableInterface only had getCacheKeys(), because that's what was relevant to the scope of that issue. About cache keys, from CacheContexts::convertTokensToKeys():

   * Cache keys may either be static (just strings) or tokens (placeholders
   * that are converted to static keys by the @cache_contexts service, depending
   * depending on the request). This is the default cache contexts service.

But, by now we're using CacheableInterface for use cases where we don't want to return any static keys, but only tokens, because the object that implements CacheableInterface is not itself cacheable, but affects the cacheability of a containing object.

In other words, we now have situations where it's confusing to implement getCacheKeys() because we want implementations to not return actual keys, but only to return tokens (cache contexts) by which the cached thing should be varied.

Proposed resolution

Add CacheableInterface::getCacheContexts().

This will allow both BlockBase() and AccessResult to be easier to understand.

When building a CID for a cacheable object, we'll just have to do array_merge($o->getCacheKeys(), $o->getCacheContexts()).

Remaining tasks

Discuss.

User interface changes

None.

API changes

CacheableInterface::getCacheContexts()


Viewing all articles
Browse latest Browse all 294680

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>