- 🇫🇷France prudloff Lille
🐛 Allow explicit bubbling of cacheability metadata inside Twig template (when accessing data from instead of rendering render arrays) Needs work is a similar discussion about cache metadata.
If a Twig template receives a variable x, but doesn't print it and instead only prints a child element, such as {{ x.y }}, then several potential problems happen:
x element has '#access' => FALSE, then the x.y element still gets printed, because the renderer never receives the x element directly in order to check its access.x element has #theme, #theme_wrappers, etc. that add something important to the rendered HTML, such as attributes for in-place editing, RDFa, etc., those get skipped, and so the output {{ x.y }} isn't in-place editable, RDFa annotated, etc.x element has cache metadata (contexts, tags, or max-age) or #attached libraries, they don't bubble up, because x is not itself rendered.Corresponding to each of the above 3 problems:
{{ x|only('y') }} for printing a single child, but with the full context of its parent?Discuss what is desired in general, and what the scope of this issue should be.
None
TBD
Active
11.0 🔥
theme system
It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.
There is consensus among core maintainers that this is a major issue. Only core committers should add this tag.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
🐛 Allow explicit bubbling of cacheability metadata inside Twig template (when accessing data from instead of rendering render arrays) Needs work is a similar discussion about cache metadata.