Something went wrong fetching the scanner findings. Please try again.
Resolve #2232375 "Make language switcher nocache"
4 unresolved threads
Compare changes
@@ -6,6 +6,7 @@
@@ -50,7 +51,6 @@ public function viewMultiple(array $entities = [], $view_mode = 'full', $langcod
@@ -61,6 +61,21 @@ public function viewMultiple(array $entities = [], $view_mode = 'full', $langcod
Doesn't this mean that the block will now bleed into the ancestors to be cached there?
In which case, the whole point of not wanting to cache LanguageBlock seems moot as it will be render cached along with the first ancestor that specifies cache keys. Oh wait no, because we will placeholder it, we will be caching the placeholder markup with the ancestor, but not the actual rendered placeholder.
But that still means that CacheOptionalInterface block plugins which are not placeholdered will fully be cached along with their parent. Are we fine with that?
It does seem to imply that optional means: "Do not cache if placeholdered, cache if not". Do we want to document that?
that's exactly the idea yes. There is a follow-up to use it on more blocks, see https://www.drupal.org/project/drupal/issues/3516051. things like the powered by or messages block are trivial, just one markup element, maybe a translatable string (which is cached too). It's hard to measure it reliably, but I doubt that a cache (+ currently a tag) lookup is faster than just rendering that.
note that even the most trivial block also involves the block template and preprocess, but still, I think external lookup is slower, especially if have a larger site with a cluster and DB/redis through a network.
Okay, then maybe we need to document that? We know how it works, but not everyone knows how the renderer and render cache work in detail. Just a small hint that caching may still occur further up the tree and if you want to avoid that, you should placeholder the block.
Agreed that documenting this is a good idea, but yeah the idea here is that:
Added documentation.