Problem/Motivation
For a long time, including in Drupal 7, it was possible to render cache something. For all that time, you had 2 ways of generating a cache ID:
- set
#cache[cid]
- set
#cache[keys]
The first is basically just a concatenated version of the second. So they were almost interchangeable. In any case, it was fine for both to exist. In practice, almost nobody uses #cache[cid]
though — almost everybody uses #cache[keys]
(because it's easier to manipulate in alter hooks, for starters).
But ever since #2158003: Remove Block Cache API in favor of blocks returning #cache with cache tags landed a year ago, we've also had #cache[contexts]
, basically cid == keys + contexts_to_keys(contexts)
. So they weren't interchangeable anymore.
And since then, about a month ago #2429257: Bubble cache contexts landed. Ever since, we have a bigger problem: cache contexts must bubble and thus must affect the cache ID generated from keys+contexts of render tree ancestors. But, we can't merge cache contexts with #cache[cid]
, only with #cache[keys]
. Hence, using #cache[cid]
effectively breaks cache bubbling.
Proposed resolution
Remove #cache[cid]
.
Remaining tasks
TBD
User interface changes
None.
API changes
Removed #cache[cid]
.
Comment | File | Size | Author |
---|---|---|---|
#2 | render_cache_cid-2459003-2.patch | 9.95 KB | Wim Leers |
Comments
Comment #1
Fabianx CreditAttribution: Fabianx for Drupal Association commented+1 to removing it, because as a user you can convert a normal $cid to keys, there is no real BC break.
Comment #2
Wim LeersEven more arguments in favor of removing
#cache[cid]
:Comment #3
Fabianx CreditAttribution: Fabianx for Drupal Association commentedRTBC - if tests pass.
Render Caching is very uncommon in D7 anyway and keys is always better, so no reason to keep this special case.
Comment #4
catchFine with the API change, very unlikely that anyone's relying on this. However it needs a change record.
Comment #5
Wim LeersCR created: https://www.drupal.org/node/2459367
Comment #6
catchCommitted/pushed to 8.0.x, thanks!
Comment #8
Wim LeersCR published.