Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I see a lot of references online to per-block cache controls, but I can't seem to find any in RC3. Did they disappear, or am I (hopefully) just looking in the wrong place? I have a couple Views (and other) blocks that are caching output regardless of any caching controls I can find otherwise. For example, if I include the current time with Twig tokens the time will not update until the cache expires.
Here are a couple references to the block-level caching controls in the UI that I was hoping to find:
http://drupal.stackexchange.com/questions/152659/has-the-block-cache-set...
https://pantheon.io/docs/articles/drupal/8/drupal-8-performance-and-cach...
Comments
Comment #2
dawehnerSo yeah views has a bug that it doesn't apply the cachability metadata of the tokens upon the rendering
\Drupal\views\Plugin\views\PluginBase::globalTokenReplacehas a bug.Comment #3
Todd Young CreditAttribution: Todd Young commentedYuck. Thanks for that!
But it happens with "plain old" stuff too, like echoing the time using Twig. The time shown the first time persists for all users until the cache expires, but I cannot for the life of me find the cache control to fix that - even if I disable *everything* I can find regarding caching. And the controls shown in the links I provided above are not visible in any of my RC3 installs. Were they removed?
Comment #4
Todd Young CreditAttribution: Todd Young commentedUpdating version to 8.0.x-dev, problem seems to persist in today's RC4 release...
Comment #5
dawehnerYeah the put dynamic things into twig is a general problem, but yeah I can't give you help
#2458763: Remove the ability to configure a block's cache max-age was the issue which removed it
Comment #6
Wim LeersYes, the block caching controls are gone, but have been gone longer than RC3. They're gone, because they're no longer necessary, and in fact are merely confusing. The code itself should specify the necessary cacheability metadata; we don't need to burden the site builder with thinking about that! See #2428805: Remove the ability to configure a block's cache contexts and #2458763: Remove the ability to configure a block's cache max-age.
If you want live timestamps, then you'll need to associate
max-age=0which disables render caching for that fragment, ormax-age=60or so to refresh it every minute.Comment #7
dawehnerWell, still, here is an obvious bugs, views doesn't support the token metadata when its replacing its tokens.
In general though also templates need a way to specify cache tags/contexts, because there is also dynamicness in there.
Comment #8
Todd Young CreditAttribution: Todd Young commentedAgreed, I'm already seeing very intuitive and plain-jane sitebuilder stuff becoming frustrating and confusing because of block caching unreachable through the UI. I don't have a super strong opinion on this, but I feel that no matter how "developer correct" we are it's still going to be a thorn for many people.
Comment #9
Todd Young CreditAttribution: Todd Young commentedI can get on board with it not being a bug, but then I guess it's a feature request for a feature that's already been nixed.
Comment #10
Wim LeersThe whole point is that site builders need not be burdened with thinking about block caching.
Every single block in D8 core and every block I've seen so far in D8 contrib modules provides cacheability metadata. There is no point in letting site builders also specify cacheability metadata, because it already is specified. Furthermore, many blocks contain other things that themselves bubble cacheability metadata. So if you would say "this block varies by permissions and URL", but the bubbled cacheability metadata says "it also bubbles by timezone and user", then the UI does not match reality. That is why we removed it from the UI, because it was impossible to make it understandable to site builders; it'd require site builders to know not only about bubbling, but about the specific cacheability metadata that the (possibly dynamic) contents would bubble. Which is utterly unreasonable and unacceptable. The experience was maddening, because the cache contexts you would select in the UI would effectively be a lie.
The fact that all block caching controls are gone is a feature. Because it means a simpler UI and fewer things the site builder needs to think about.
A contrib module is more than welcome to bring this back, but be aware that it will be equally maddening.
#7:
That is definitely a bug. But that's not what Todd Young is referring to first and foremost. So, I created a separate issue for both of those things, otherwise we will keep mixing all three things here:
Comment #11
Todd Young CreditAttribution: Todd Young commentedNice summary of the three open issues, thanks for that. Perhaps the Twig and Views fixes get us 92% of the way there, and then yes - we could put a contrib module out for the edge cases. I think the specific point of such a module wouldn't be to make caching maddening by conflicting with what core does; I'm not looking to establish all sorts of rules and granularity...
I just want the ability to tell a block to "definitely not cache at all ever" to override whatever else would have happened for that specific block. I think the subtractive approach would be pretty intuitive and very helpful to the community.