- 🇬🇧United Kingdom catch
Not the same thing but given they both affect SystemMessagesBlock adding the placeholder strategy denylist issue too - both are based on the system messages block being extremely cheap to render overall.
- 🇨🇭Switzerland berdir Switzerland
As quickly discussed on slack, changing how the links are build is challenging because it's a pluggable system depending on your language negotiation settings. See \Drupal\language\Plugin\LanguageNegotiation\LanguageNegotiationUrl::getLanguageSwitchLinks, session/cookie based language adds its own query parameter that it then uses on the given request to put it back into a cookie. It's not impossible but tricky with BC and relying on this happening and so on.
FWIW, I'm reasonably certain that building this is faster than fetching from cache, based on renderering time debug output (had to hack it to show times also for non-cacheable elements), it's also the same right now in HEAD. But there might indeed be edge case such as it being the only thing it has to render with twig.
I also verified that this fixes OpenTelemetryFrontPagePerformanceTest.php with 🐛 [pp-3] Bubbling of elements' max-age to the page's headers and the page cache Postponed , which currently fails as this block prevents it from being a page cache hit.
It's also no change compared to HEAD. The block is currently being autoplaceholdered and not cached as well, just also in a way that that information up.
I also created 📌 Add CacheOptionalInterface to more blocks Needs review as a follow and want to add a change record for this.
- Issue created by @berdir
- 🇬🇧United Kingdom catch
🐛 Page cache creates vast amounts of unneeded cache data Active is getting more attention recently (maybe more bad crawlers around?), and the dynamic_page_cache not varying by query parameters unless it actually has to is one of the mitigations for that issue. Both varying the dynamic page cache by query params, or introducing a separate cache item that does, would make that particular issue worse for people I think. So for me that leads strongly towards option #c.
I did think of one other possible approach when reading the IS:
What if we made a special placeholder (similar to CSRF placeholder handling) for only the query string and replace only that? Then we could remove the query string cache context but handle it all in PHP still.
This also made me wonder how bad would it be if we dropped the query string entirely - usually when I change language on a site I'm either testing, or it's the first thing I do when I land on the site, not 5 pages into a pager (which might not show the same results anyway). But probably if we did that someone would be relying on it somewhere.