When not using CK Editor and hand-coding footnotes, should "Convert line breaks fiilter" not convert line breaks when within footnotes?

Thanks for the report. Someone can look into this of course but clarifying the title + moving status as this is really isolated impact, does not affect the main usage of the project, and has a valid workaround:

1) The site builder has to decide not to use CK Editor
2) The content editor has to add line breaks within an inline element

Arguably, if you add a line break you should expect it to be converted to a line break. There is also ✨ Trim footnotes text via drush command upgrade path from 3.x to 4.x Active which I have tried to support you with, to auto fix line breaks incorrectly added so that if upgrading, that situation can be changed.

So the first question here really is should this be changed? If you add a line break, should you not expect that to result in a br if you also expect all other markup within the footnote to be outputted? My opinion: if you want markup inside footnotes you should expect all markup within footnotes and not selectively choose some and not others.

Open to other opinions but probably at the very least it should be a checkbox in the filter settings like 'Ignore line breaks within footnote reference texts' that content editors could opt-in to or we will just get bug reports the other way around.

@John_B up to you if you want to submit a patch or alternatively review the drush upgrade command that is there to fix the problem and remove the line break. Otherwise let's see if others share your opinion and want to contribute this feature.

A content editor not using CKEditor is no edge case. It was Drupal default until D8. There must a lot of legacy countent out there from the two decades from the start of Drupal to D7 EOL in 2025, using Drupal < D8's non-WYSIWYG default. This content may suffer during migration from D7. Drupal during those two decades has claimed 'we will break your code but we will never break your data'.

For the sake of argument let us say it is an edge case. Let us say content editors should not be inserting line breaks, and that it is now OK to break legacy content. We then have a Footnotes filter which works correctly with perfect markup, but is fragile, because it can be broken by a small error in markup. This is not ideal and should at least be documented.

The problem with ouputted markup messing up the footnotes.css grid, if the core line break filter runs after Footnotes filter, should also be documented.

Can you explain what you mean by broken/messed up? It is all very theoretical without seeing it. Perhaps you can provide a screenshot and I can see if it might be solved eg with twig or css?

'we will break your code but we will never break your data'

This does not mean we should maintain what was arguably taking advantage of a past bug that is now fixed (ie, line breaks not showing up as line breaks, but now they are). ✨ Trim footnotes text via drush command upgrade path from 3.x to 4.x Active was an attempt to help you migrate content away from that.

Anyways, let's see the screenshots, perhaps you can work around it with modifications to twig or css like |trim or other such features of twig.

There is also by the way nothing stopping you from continuing to use 3.x. 3.x to 4.x is a major release which has a migration path, not an upgrade path. If someone wants to continue to submit patches to 3.x that's perfectly fine. If you are not using CK Editor 5, I am not sure what the advantage of switching to 4.x is.

The new version is not an issue for us if we can plan our content creation workflow on the basis that 3.x., which works very well, will not be abandoned.

By messed up I mean the following. My node content is as follows:
Body text.<footnotes data-value="">Footnote text.</footnotes>

If the core "Convert line breaks" filter runs after the footnotes filter, the footnote is printed to the browser as follows:

<li class="footnotes__item-wrapper js-footnote-reference ">
        <span class="footnotes__item-backlinks"><br>
                      <a class="footnotes__item-backlink js-is-auto" href="#footnoteref1_mUdvmeD9P6xi" id="footnote1_mUdvmeD9P6xi">1</a><br>
                  </span><br>
        <span class="footnotes__item-text">Footnote text.</span>
      </li>

Those br tags cause the footnotes.css grid to output the footnote in a narrow column, as in the screenshot.

The new version is not an issue for us if we can plan our content creation workflow on the basis that 3.x., which works very well, will not be abandoned.

I personally will not be spending my of my free time on 3.x. There are other maintainers which I cannot speak for of course, though they have been very quite for some time. So it is a fair point.

Thanks for the details. Will take a look.

Okay, looks like you have development.services.yml set to debug: true. Applying spaceless to footnote-list.html.twig sorts the references section (see MR) but the citation itself that does not work unless you turn off debug: true mode.

That bit is really a conflict between twig debug and Core's "Convert line breaks into HTML (i.e.
and

)" filter - see 🐛 The filter "Convert line breaks into HTML (i.e. and )" generates duplicate br tags after a line ending in a break tag that doesn't exactly match Needs review .

With the merge request patch applied, here is that with debug set to false:

And here with debug set to true:

So I can apply spaceless to the default template for the references, but as noted, it only sorts part of this, and the other part is out of the control of the module.

Many thanks.

Turning off debug mode deals with most of the <br> tags. It fixes the formatting problem for the footnote reference in the body text.

There is still one br tag between footnote number and fonte text, as follows:

<li class="footnotes__item-wrapper js-footnote-reference ">
        <span class="footnotes__item-backlinks"><br>
                      <a class="footnotes__item-backlink js-is-auto" href="#footnoteref1_jV2bEcWE6rfv" id="footnote1_jV2bEcWE6rfv">1</a><br>
                  </span><br>
        <span class="footnotes__item-text">Footnote text.</span>
      </li>

This creates a problem with the footnote grid, as shown in the screenshot:

I should add that the above problems only occur if the "Add line breaks" filter runs after the footnotes filter. To my mind, it is OK to require it to run before the footnotes filter, if it is documented. This does work if debug is disabled. Therefore setting to RTBTC--though the limition does need to be documented.

Thanks, I also raised 🐛 FilterAutoP should ignore twig.config debug html comments Needs review in Drupal Core as it seems that it would be better if there were not such differences between live & dev environments for this

Automatically closed - issue fixed for 2 weeks with no activity.