Provide non-deprecated replacement for Twig "spaceless" filter

Did a pass on this, great work!

1. Went through all changes
2. Double checked we have no spaceless left
3. Tried to validate a consistent change around all tags.

Have some questions on ~ tag, some incinsistentencies when we do the - for spaceless and would prefer less magic in the expected strings of the tests. I'm not that well versed in twig :)

I've rebased and answered some questions.

Went through the awnsers and replied. Also needs a rebase :)

@bbrala
please take a look at failed test output. can you tell me what is wrong? :)

https://issue.pages.drupalcode.org/-/drupal-3477375/-/jobs/2898571/artif...

https://gyazo.com/4472bf82dbea1314e6dee9cf2a460514

Hmm, very weird.

What im thinking is it might be the fact that we have real vs character newlines. I tried to get the same error locally on that test, didnt workt.

We could try making it real newlines:

$expected = '<div class="link-item"><div class="link-url"><a href="' . Html::escape($url) . '">' . Html::escape($url_title) . '</a></div>\n </div>';

change to

$expected = '<div class="link-item"><div class="link-url"><a href="' . Html::escape($url) . '">' . Html::escape($url_title) . '</a></div>
 </div>';

or

$expected = '<div class="link-item"><div class="link-url"><a href="' . Html::escape($url) . '">' . Html::escape($url_title) . "</a></div>\n </div>";

And see if that resolves it.

@bbrala, probably let's create followup issue here? And for now will test whitespace/newlines trimmed results?

I've done a very small update, replacing \n with PHP_EOL and seems tests are green. This is technically fully your solution just changes the newlines.

See: https://git.drupalcode.org/project/drupal/-/merge_requests/9665/diffs?co...

Will need to check if we have adressed all comments though, i'll get backl to that, or someone else might.

We still have dropdown with same trim spaces

I will do an extra iteration, i think we could make tests work with only a very small change.

Yay got all green, now just some small optimizations to minimize the changes.

Tests are all green, and the only thing changes in the tests are a few newlines.

I can't RTBC anymore though. I'll go find someone for that :)

The MR needs a rebase.

just did it.

#20 xposted with the actual rebase. RTBC.

This is eventually going to break quite a few, if not the majority of custom and contributed Drupal themes.

Is this something that automation will be able to help with? Just a couple years ago, people were explicitly advised to use the filter, as the tag was going away.

Hmm, maybe. I could check but that will take some time. Sometimes the resulsting data might also have whitespace.

I'll try and make some time to go through each and try if can be removed.

Steps:

1. Find candidate
2. Remove and push
3. Wait for tests
4. Next

Unfortunately the test doesn't want to run locally for me. :(

I intially throught it would also remove whitespace between html tags in the variable. Let's see how wrong i was :)

This is eventually going to break quite a few, if not the majority of custom and contributed Drupal themes.

Is this something that automation will be able to help with? Just a couple years ago, people were explicitly advised to use the filter, as the tag was going away.

Hmmz, yeah it is gonna be quite discurptive. Basically we need to remove the spaceless tags, which would be fine. Its easy enough to make a script that removes those tags in twig templates. So in a way this could be added to update bot to fix. Although it would be something "special" since it wouldn't be rector really. So what the correct place for that is, that is something that needs some thought.

All green without most of the whitespace stuff. @longwave did raise the question if these changes could lead to layout shifts. I find that hard to know. Hopefully someone can say something smart about that.

Adding credit for 2 colleagues who went through it all.

I've fixed all the issues timo and cees identified. Think every single change has now been reasoned about. Ready for review again.

Added some credits. Commiter needs to decide on @mondrake

All the raised concerns that we discussed this morning are resolved. RTBC

Please do not credit me. The review I did was surfacing and not the deep dive that was required.

Arg that's pretty annoying. We were hoping the fact is uses link template would remove all spaces around that.

Only one behind it it seems?

I also got nod to promise to take a look, he'll know what to expect.

I'll do an install and fix the author. See if I can validate a few, just worried I cannot replicate all templates. Hopefully have time for that tonight.

ANother one

<div class="tabledrag-cell-content js-tabledrag-cell-content"><a href="#" title="Change order" class="tabledrag-handle js-tabledrag-handle tabledrag-handle-y"></a><div class="tabledrag-cell-content__item">Primary admin actions</div></div>

Height is wrong for the rows.

Draggable rows seem misaligned, more than that i cannot find.

Seems like we'll have to backport spaceless to our repo:

1. Normal HTML behavior: a new line is rendered as a space, which cause the problem with "submitted by"
2. Extra Drupal spice on the issue: when twig debug is turned on, it adds newlines all over the place

<span>
          By <span><a title="View user profile." href="/en/user/6">Umami</a></span>, 15 September 2024
        </span>

<span>
          By <!-- THEME DEBUG --><!-- THEME HOOK: 'field' --><!-- FILE NAME SUGGESTIONS:
   ▪️ field--node--uid--article.html.twig
   ✅ field--node--uid.html.twig
   ▪️ field--node--article.html.twig
   ▪️ field--uid.html.twig
   ▪️ field--entity-reference.html.twig
   ▪️ field.html.twig
--><!-- BEGIN OUTPUT from 'core/modules/node/templates/field--node--uid.html.twig' --><span><!-- THEME DEBUG --><!-- THEME HOOK: 'username' --><!-- 💡 BEGIN CUSTOM TEMPLATE OUTPUT from 'core/themes/olivero/templates/user/username.html.twig' --><a title="View user profile." href="/en/user/6">Umami</a><!-- END CUSTOM TEMPLATE OUTPUT from 'core/themes/olivero/templates/user/username.html.twig' --></span><!-- END OUTPUT from 'core/modules/node/templates/field--node--uid.html.twig' -->, 15 September 2024
        </span>

<span>
          By
<span><a title="View user profile." href="/en/user/6">Umami</a></span>
, 15 September 2024
        </span>

<span>
          By

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'field' -->
<!-- FILE NAME SUGGESTIONS:
   ▪️ field--node--uid--article.html.twig
   ✅ field--node--uid.html.twig
   ▪️ field--node--article.html.twig
   ▪️ field--uid.html.twig
   ▪️ field--entity-reference.html.twig
   ▪️ field.html.twig
-->
<!-- BEGIN OUTPUT from 'core/modules/node/templates/field--node--uid.html.twig' -->

<span>

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'username' -->
<!-- 💡 BEGIN CUSTOM TEMPLATE OUTPUT from 'core/themes/olivero/templates/user/username.html.twig' -->
<a title="View user profile." href="/en/user/6">Umami</a>
<!-- END CUSTOM TEMPLATE OUTPUT from 'core/themes/olivero/templates/user/username.html.twig' -->

</span>

<!-- END OUTPUT from 'core/modules/node/templates/field--node--uid.html.twig' -->

, 15 September 2024
        </span>

I do not see a way to make this work with only twig whitespace control features.

it's a good idea to remove it where it's not needed. I don't think it's worth it to remove it at all costs though, it's applied on pretty small strings, not whole pages so performance impact shouldn't be too bad to begin with. We're not using this to minify a whole page so that doesn't appy to us.

If we need to keep it, I wonder if there is a way our then by overriding the spaceless tag so we don't trigger the deprecation. This would also be very helpfull for theres who might use it.

We might be able to something like we do in #3474692: Fix "Twig\Node\Expression\FilterExpression" deprecation introduced in twig/twig 3.12.0 then and override the spaceless filter.

This is how it is called in Twig itself:

new TwigFilter('spaceless', [self::class, 'spaceless'], ['is_safe' => ['html'], 'deprecated' => '3.12', 'deprecating_package' => 'twig/twig']),

Made a quick MR to test replacing the filter.

Ok, that approach will need more work. Was hoping for a quick one. Don't want to dive into my debugger right now and see when we can inject or override somehow.

Personally i would also rather use it only when needed like longwave suggests. There are quite a few places where it could be quite harmless to remove.

Well, it does work, but since the old one is loaded anyways before we replace it in the visitor it does actually trigger the deprecation. So not sure if we can even fully disable the deprecated one in CoreExtentions and have no error.

This might mean we need to actually replace the tag.

May be a way out if we would load the druapl extentions before twig core extention, but that would mean maintaining the full contructor.

Hmmz. Can't we fix the debug output to not add newlines before/after or something? Or is there way more places where this will become an issue?

if we remove the newlines from debug output it'll be unreadable and will defeat the purpose of having it in the first place. It needs to be human readable output with how things are today. If we had a dedicated debugger or inspector we could get around that but we're not there yet and I don't know of anyone working on such tooling.

Isnt the issue that there is extra newlines before/after/between tags, not nessesarily in the comments. The comment could still be formatted, we just need the output not to use newlines around them? We could even apply a drupal_spaceless filter on that specific node when it is visited by our nodevisitor and have that output be ok? But then again, we might as well replace apply spaceless with apply drupal_spaceless and start helping contrib move along.

Still though, that would not solve the fact it is deprecated and the fun contrib will have with spaceless being gone. Been looking at replacing it with out own, but the deprecation error is thrown when when the parser is doing its work. Since we cannot without to much effort get into that part of twig seems we cannot really do much.

Is there potential here to approach this a bit more seamlessly?

For example, can we detect if spaceless exists upstream and only if it does not, add a twig function that matches the contract 100%?

  // @TODO: Remove 'if' check when we require a version of twig that doesn't ship with spaceless.
  if (upstream spaceless does not exist) {
    // Replace removed upstream spaceless filter with our own.
    new TwigFilter('spaceless', [self::class, 'spacelessFilter'], ['is_safe' => ['html']]),
  }

This would mean zero disruption to downstream clients.

Rationality for keeping it around is that there really isn't a direct replacement for it.

Assume variable contains <span>Hello</span> <span>There!</span>

  {% apply spaceless %} {{ variable }} {% endapply %} --> renders "Hello There!"

is not equivalent to

  {{- variable -}}  --> renders "HelloThere!"

This is a MASSIVE b/c breakage upstream.

If we want to keep spaceless, what about @lleber's conditionally defined filter (or we don't even necessarily need that, just an issue since it'll only be removed in a major twig release) as well as setting a custom error handler before we call Twig to suppress the deprecation message?

The solution with the drupal_spaceless would work, the issue is that the deprecation message is triggered in the ExpressionParser. This is really early in the process, and i have not found a way to really hook into that early enough.

We might be able to do some 'hackery' to adjust the specific filter in CoreExtention to not have deprecated. But i've not found a way for that.

@luke.leber

your #55 assumption is incorrect

{% set var = '<span>Hello</span> <span>There!</span>' %}
{{- var|raw -}} -> renders Hello There!

Spaces trimmed from begin and end

At the moment i'm moving trough templates and checking visual regressions.
I don't think we need to add extra filter

I was also thinking of using composer autoload to override a class to fix this, but that would mean overwriting a big class like CoreExtension, or smaller TwigFilter, but that does kinda feal like using a hammer to screw in a screw. We could though override TwigFilter, its quite a small class, but that adds complexity when updating at some point.

Re- #58

See https://fiddle.nette.org/twig/#3c6dbf089c

There is certainly changes in the generated output such that whitespace control operators are not a direct replacement for spaceless.

catch makes a good point in #56. The if statement could probably just be a version check on the twig dependency.

My main point here in #55 is that we probably shouldn't reimplement spaceless with a new filter name, as that would just cause needless untold fatal errors in custom and contributes themes on upgrade where it could otherwise be avoided if the same filter name is used.

re #60 the fiddle is using outdated version (3.7.1) but deprecation is since v3.12.0 and using PHP backend (not JS)

I've tested templates before/after patch.
WIth/without twig debug.
Templates without regressions marked with +

core/modules/block_content/templates/block-content-add-list.html.twig +
core/modules/ckeditor5/templates/ckeditor5-settings-toolbar.html.twig +

core/modules/link/templates/link-formatter-link-separate.html.twig
fixed(looks as before now)

core/modules/link/tests/themes/link_test_theme/templates/link-formatter-link-separate.html.twig
revered `-` signs there. Now works as before with/without twig debug

core/modules/system/templates/dropbutton-wrapper.html.twig +
core/modules/system/templates/select.html.twig +
core/modules/toolbar/templates/toolbar.html.twig +
core/profiles/demo_umami/themes/umami/templates/classy/field/link-formatter-link-separate.html.twig +
core/profiles/demo_umami/themes/umami/templates/classy/navigation/toolbar.html.twig +
core/themes/claro/templates/classy/field/link-formatter-link-separate.html.twig +
core/themes/claro/templates/classy/navigation/toolbar.html.twig +
core/themes/claro/templates/form/input.html.twig +
core/themes/claro/templates/navigation/toolbar.html.twig +
core/themes/claro/templates/views/views-mini-pager.html.twig +
core/themes/claro/templates/pager.html.twig +

core/themes/olivero/templates/content/node--teaser.html.twig
fixed visual regression with css
it related to core/modules/node/templates/field--node--uid.html.twig which i don't want to change here

core/themes/olivero/templates/content/node.html.twig
same CSS fix plus extra wrapper.

core/themes/olivero/templates/content/search-result.html.twig +
core/themes/olivero/templates/navigation/pager.html.twig +
core/themes/olivero/templates/user/username.html.twig +
core/themes/olivero/templates/views/views-mini-pager.html.twig +
core/themes/stable9/templates/admin/block-content-add-list.html.twig +

core/themes/stable9/templates/admin/block-content-add-list.html.twig +

core/themes/stable9/templates/field/link-formatter-link-separate.html.twig
fixed(looks as before now)

core/themes/stable9/templates/form/dropbutton-wrapper.html.twig +
core/themes/stable9/templates/form/select.html.twig +
core/themes/stable9/templates/navigation/toolbar.html.twig +

starterkit didn't checked. just reapplied fixes

Probably this custom filter can be moved to temporary module?
To make contributors life easier.
Core obviously doesn't need it. All regressions fixed

Does it work when debug comments are present?

yes, i've tested in both modes

Revisiting the idea of replacing the spaceless filter: It happens that if a Twig extension is added to the environment that has a filter with the same name as a filter in an extension already added to the environment, then the filter definition in the extension added last takes precedence. I've added a commit to MR 9735 that adds a SpacelessBCExtension class after Twig's CoreExtension is added to the Twig Environment. The spaceless filter is currently defined in SpacelessBCExtension without deprecation warnings, and all tests now pass. Could also change it to issue a different deprecation message to use drupal_spaceless instead by Drupal 12.

I'm so confused. I tried that earlier. But yay!

Should the effort to replace all usage of spaceless in core templates (MR 9665) and the effort to suppress the spaceless filter deprecation warning + add drupal_spaceless filter (MR 9735) be combined into one MR?

Also, should Drupal have its own deprecation message for spaceless usage, with a recommendation to change to drupal_spaceless?

What is the benefit of changing the name of the spaceless filter in a non-bc way?

Maybe I'm dense, but not causing excess contrib and custom disruption should be a chief consideration in the decision making process, right?

The `spaceless` filter in Twig was deprecated as of version 3.12. To address this deprecation, you should remove the `spaceless` filter from your Twig templates. Instead, rely on HTML minification tools, like AdvAgg or HTML Minifier, or front-end build tools to minimize whitespace in your output. Additionally, CSS can be used to manage whitespace rendering. Removing the filter ensures compatibility with future Twig versions.

Hello,

Verified on Drupal 11 without patch its looks fine for me.
Not able to reproduce using patch getting error.
Attaching screenshots of without patch and error.

Yeah we had this issue in the footnotes module (#3486119: Fix deprecated spaceless issue) because spaceless is quite important to avoid inline citations having spaces around them. Perfectly happy though to have a mini footnotes_spaceless twig filter to cover that. If it turns out its needed by more modules, we can always switch to depending on something in contrib.

issue summary is not up to date. We should probably open a different issue to remove the use of spaceless in core and leave this one to deal with the deprecation or polyfill for contrib is needed.

Can someone open an issue with the code from MR !9665 ? thanks!

Updated IS, created follow up to remove spaceless usage in core (#3486170: Remove use of deprecated "spaceless" filter in core templates), and added a test that the spaceless filter still works as expected.

Hello,

Verified on Drupal 11 without patch its looks fine for me.
Attaching screenshots.

RTBC

Moving to RTBC per #77.

This looks great everyone, nice work!

rebased to bring it up to date with the latest 11.x

Is this needed now that #3486170: Remove use of deprecated "spaceless" filter in core templates has been committed? spaceless no longer appears in Drupal core.

The deprecation/removal in the future will cause another major rework of twig templates in contrib/custom modules and themes. I think the goal was that core can keep it for BC reason and it to avoid this disruption.

@liam morland: #3486170: Remove use of deprecated "spaceless" filter in core templates was split from this issue per request in #74.

Since using MR as a patch is a security issue, a new patch has been provided.

Are we sure we want to do this. Why did Twig remove the filter?

Also the issue summary and title need work.

Why do we have both drupal_spaceless and spaceless? Seems unnecessary too introduce drupal_spaceless

IS updated.

Are we sure we want to do this. Why did Twig remove the filter?

Per https://github.com/twigphp/Twig/pull/4236

Deprecate the spaceless filter for the following reasons:

• The performance is bad (as the work is done at runtime via a regexp)
• Optimizing the size of an HTML doc server side is "almost never" a good idea (compression is better and enough)
• There are some edge cases where you want to keep some spaces (see https://github.com/twigphp/Twig/issues/3576
• Controlling whitespace is possible and fine-grained via the dedicated Twig modifiers on {{ }}

If someone find it useful, re-creating it is trivial (return trim(preg_replace('/>\s+<', $content ?? ''));),
but with so many caveats and not so many use cases, I think it does not belong to core.

The rationale for keeping it is that it likely will be very disruptive for a lot of contrib/custom projects, some of which previously had to refactor their templates when Twig deprecated and removed the spaceless tag.

Why do we have both drupal_spaceless and spaceless? Seems unnecessary too introduce drupal_spaceless

Added commit to remove drupal_spaceless.

It be great to have a spaceless placeholder as to have backwards compatibility.
The docs could start pointing people towards the new solution in the mean time and glitches can be worked out as those migrate.
Rather than everyone migrate now and hope for the best.

OK to add it but should be also deprecated and encourage projects to use https://twig.symfony.com/doc/3.x/templates.html#templates-whitespace-con...

Can we get a CR for new extension?

OK to add it but should be also deprecated

Twig is emitting its own deprecation message for spaceless that it will be removed in Twig 4. AFAICT, there's no calendar for the Twig 4 release, so while we can add a deprecation message here for how long Drupal will support it, I think that won't be known until we know what version of Drupal will use or require Twig 4. Assuming that we want to provide BC support spaceless at all.

Can we get a CR for new extension?

I don't think it needs one? It's just there to override Twig's spaceless filter to suppress its deprecation message. I've added final and @internal to the class be sure.

Well if it's meant to be permanent in Drupal shouldn't that be announced? Also if permanent SpacelessBCExtension is the BC part needed?

Well if it's meant to be permanent in Drupal shouldn't that be announced? Also if permanent SpacelessBCExtension is the BC part needed?

There probably should be a CR for what the support policy will be for spaceless, but there needs to be agreement/direction on what that should be. There are questions about whether this should be done at all, or Drupal should emit a its own deprecation message, or if it's long-term support.

I don't think that SpacelessBCExtension specifically needs a CR, since it's internal implementation details that's not API.

Hi everybody,

It may be the good opportunity to try to stop adding Twig extensions and start to stick as much possible with upstream Twig. We have added a lot of extensions (functions, filters...) during the Drupal 8.x lifecycle and some of them are technical debt now we are moving to a UI component workflow with SDC (for example, the ones calling Drupal API from templates).

The rational the Twig team has shared about this deprecation makes sense https://github.com/twigphp/Twig/pull/4236

@mdsohaib4242:

Removing the filter ensures compatibility with future Twig versions.

Exactly. Can we follow the upstream deprecation instead of hiding it? And focus on #3486170: Remove use of deprecated "spaceless" filter in core templates for Core. For Contrib, we will move to Twig 4.x in a Drupal major (12.0 ? 13.0 ?) version anyway.

About @nod_ feedbacks in #43

Normal HTML behavior: a new line is rendered as a space, which cause the problem with "submitted by"

Extra Drupal spice on the issue: when twig debug is turned on, it adds newlines all over the place

Can we consider this as bug related to fix in Drupal scope ("submitted by" template and our own flavour of Twig debug)?

@pdureau #3486170: Remove use of deprecated "spaceless" filter in core templates has already been committed to 11.x. Only thing outstanding there is whether a port to 10.5.x is required. I believe that addressed #43 already.

Only thing outstanding here is whether Drupal core should provide spaceless to ease contrib/custom template concerns, but if not, then this issue can probably be closed/won't fix.

Only thing outstanding here is whether Drupal core should provide spaceless to ease contrib/custom template concerns

I would say yes. But it should be already deprecated in 11.x for removal in 12.x so we let contribute & custom code to prepare

I would say yes. But it should be already deprecated in 11.x for removal in 12.x so we let contribute & custom code to prepare

Twig is already emitting its own deprecation message. If it ends up that Drupal doesn't move to Twig 4 until Drupal 13 , then overriding the deprecation message for removal in 12 seems premature.

Re #95:
I think that a major issue is that there is no equivalent way (or at least an easy way working generally for all use-cases) to replace the functionality it provided. I think that core can manage it, but for contribs and custom themes/code, it will add a lot of work. If you look at the related issue (#3486170: Remove use of deprecated "spaceless" filter in core templates), not all changes were just removing the filter and adding some whitespace controls. And lot of these changes needs to be tested manually, because it has a potential to disrupt layouts and so. So I see a benefit of providing our replacement until we decide to deprecate and remove it entirely (as proposed in IS), to help the contrib world with the transition (though I am not sure when Twig 4 is planned).

So instead of adding to core would this make sense as a contrib module, maybe even in twig_tweak?

So instead of adding to core would this make sense as a contrib module, maybe even in twig_tweak?

I came here to say the very same thing.

If spaceless is deprecated in Twig officially and we are not using it in core any more, and our fix is just to solve issues that _might_ arise in contrib, this seems perfect to become a contib module (or a Twig Tweak - as you suggested - feature).

Any objection to moving this to twig tweak then?

Echoing #97 claudiu.cristea — “I would say yes.” Drupal Core should ease the transition in 11.x and fully remove it in 12.x.

I don't grok what is suggested in #98 sorry @godotislate

@pdureau #95 can you point me to the technical debt you are speaking of, I was responsible for some of it, so I am curious what I broke in the future!

I don't grok what is suggested in #98 sorry @godotislate

Last I checked, there's no schedule or announcement about when Twig 4 will be released, which is when spaceless will be removed from Twig.

If Twig 4 is released after Drupal 12, then Twig will still provide spaceless, so it won't really be removed in Drupal 12.

This is a tough one as everyone seems split almost 50/50

Still think contrib makes more sense though. If it were added to core that puts ownership and responsibility of a feature that has already been removed.

I think twig tweak makes the most sense as a landing place but even its own module

@pdureau #95 can you point me to the technical debt you are speaking of, I was responsible for some of it, so I am curious what I broke in the future!

Sure @joelpittet

Most of the Drupal-specific Twig functions added in 2015, during the development of Drupal 8.0, are requesting the Drupal application state:

• active_theme() & active_theme_path() are requesting the ThemeManager service
• attach_library($library) may reference a "business" library from a module and is executing an early rendering
• link($text, $uri, $attributes) (from #1777332: Replace theme_menu_link() and menu-tree.html.twig with a single Twig template) is able to manipulate a stateful URL object which would be better resolved before reaching the template
• url($name, $parameters, $options) & path($name, $parameters, $options) (from #2073811: Add a url generator twig extension) are manipulating application routes (). This would be better be resolved before reaching the template.
• file_url($uri): I have never used it but it may be a similar situation

Other functions have their own kind of issues:

• render_var($arg): it is OK for internal use in TwigNodeVisitor but not directly in templates to avoid early rendering
• create_attribute($attributes) : #3457874: HTML attributes as Twig mappings instead of PHP objects

Some filters have similar issues (|render(), |add_suggestion()...)

You broke nothing 😉 Thanks you so much for having led most of those additions in 2015. Those functions were great and pragmatic when they were implemented 10 years ago, they made the conversion from PHP Templates (using functions like theme_link()) to Twig easier and the community-wide transition a success.

However, they may not fit with the new, design-system oriented, paradigm started with SDC, where the UI component needs to encapsulate business-agnostic UI-logic only and stays "dumb" & stateless. On any website, any context, with the same values injected in slots & props, always return the same markup.

So, if we are going this way, we are starting a long transition phase when those additions may be less and less needed, and we may be able to remove them one day, getting a bit closer to the vanilla Twig templating.

Comment #108 moved to its own issue #3533198: [Meta] Make Drupal the first "design-system native" CMS + Unify & simplify render & theme systems

Sorry, wrong issue.

I checked just now, and I haven't found an expected release date for Twig 4.

There's still time to think about this, but if Twig 4 is not released before Drupal 12, should core support spaceless through Drupal 13? Presumably if not before D12, Twig 4 lands before D13.

Just re-upping https://fiddle.nette.org/twig/#3c6dbf089c re: #58 / #61.

I'm not opposed to the change but just want core committers to be aware of things (in that the spaceless filter penetrates into variables whereas whitespace control operators do not seem to.

In our case specifically, refactoring this caused problems with centered content (one space before or after caused things to misalign and needed other template updates to rectify).

If you forked the spaceless filter into your module to avoid the deprecation (as I've seen some people do), you should read this and apply the Symfony fix to your copy of the filter: https://symfony.com/blog/cve-2026-46628-the-spaceless-filter-implicitly-...