Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem
When block cacheability was introduced in #2375695: Condition plugins should provide cache contexts AND cacheability metadata needs to be exposed this was implemented by merging in the cacheability metadata of all potential displayable blocks. The reason for this is clear, a block might currently not be displayed, but it might be when e.g. the cache context changes, or when a relevant cache tag is invalidated. So it makes sense to put the merged cacheability metadata of every block that is potentially displayed onto the blocks' region.
However this has an unwanted side effect: if a region contains even a single block that has max-age = 0 then this will mean that this region will never be cacheable, effectively disabling caching on every page that displays this region. For many sites this will mean that a single uncacheable block will turn the entire website uncacheable.
We should mitigate this by figuring out which blocks are actually potentially visible. For example, if a website displays (uncacheable) facet blocks on the search page, then this should only cause the max-age = 0 to be applied to the search page, not to all pages.
Similarly, if a block has its visibility set to only display on nodes of type "Article", then this should not affect any pages that don't show nodes, or show nodes of other types.
The problem is located at the end of BlockPageVariant::build() where the cacheability metadata of all blocks is merged in and applied to the root of the render array.
Proposed resolution
Up to debate.
Comments
Comment #2
berdirWas confused at first because we only consider access cacheablity metadata there.
But of course the last line \Drupal\block\BlockAccessControlHandler::checkAccess() is the problem, that adds the block cacheablity metadata.
I think we can try to change that to specifically only add the cache tag, so we update it for things like saving the block and changing its configuration, but not weird cache contexts and cache max age.. we shouldn't care about that on that level if it was not *explicitly* added to the access result.
Comment #3
fabianx commentedI think the main problem with that is that the auto-placeholdering can't kick-in, because the access check is happening before actually rendering it, which is both good and bad.
Good for sections of the page being dependent ob blocks visible or not, bad for auto-placeholdering, which was created to solve this problem.
Comment #11
mxr576So is there a new/old idea how to fix this issue?
Comment #15
larowlanAdding some tags
Comment #16
catchThe code hasn't changed here so pretty sure this is still valid.
This is a microcosm of the problems with #2352009: Bubbling of elements' max-age to the page's headers and the page cache, so adding as a related issue.
One possible approach here would be to merge cache tags onto the region (since those will affect whether a block is displayed or not), but not max age or cache contexts (which generally won't, or should be explicitly in the access checks if they do) - this is what Berdir suggests in #2 as well if I'm reading this correctly.
IMO easiest step here would be a failing test that puts a block with max-age 0 into a region, and then checks the cacheability of the region, then we can evaluate the fix against that.
Comment #17
geek-merlin>
Throwing away part of cacheability (context and max-age) by not bubbling up is a break of contract and a BC break. Domain context is a simple example.
Of course a completely uncacheable page is bad. Fabianx pointed in #3 to autoplaceholdering.
Comment #18
geek-merlinComment #19
berdirWe would still respect any cacheablity added to the access result (and make it uncacheable if necessary). We only support autoplaceholdering for single blocks once we know whether or not a given block is allowed. All blocks of all regions are rendered at once, making regions auto-placeholderable would be a huge change
Comment #20
geek-merlinThanks for elaborating! Maybe the proposed solution needs a more thorough explanation, and a draft CR with its ramification.