Unwanted whitespace after footnote number during drush upgrade from 3x to 4x

Would you consider consider upgrading to the 4.x branch?

Yes, just gave it a first try, but run into this new issue 🐛 Translated content not updated from 3 to 4 syntax Fixed with translated nodes.

Thanks for flagging, I replied there + created a Merge Request that should solve

Going to mark this as outdated now that 🐛 Translated content not updated from 3 to 4 syntax Fixed is in. Thanks!

Using the 4.x branch works fine for new content.

But now I found during the drush conversation run, there will also be a whithespace inserted after the footnote number.

Example:

1. Insert content having 3.x syntax using CKEditor 5 source code editing:
Lorem ipsum[fn]Footnote text[/fn]. Dolor met...

2. run drush footnotes:upgrade-3-to-4 node

3. This results in following (CKeditor source view):
Lorem ipsum<footnotes data-text="Footnote text" data-value="">&nbsp;</footnotes>&nbsp;. Dolor met alpis.

The second $nbsp; before the puctuation is the problem here.

Thanks for the details. Updated issue summary and title to reflect this + reopened the issue.

Looking at this, I cannot reproduce. Added a test as well to show that the punctuation does not get a space after it in default circumstances, so I think I need more information about the configuration to be able to reproduce this - hope you can help.

There is this issue in core that might give a hint: 🐛 FilterAutoP should ignore twig.config debug html comments Needs review - if you have twig debug enabled with filter auto P on, since it is now a twig template rendered within WYSIWYG like a media entity is, twig debug can cause extra space. Perhaps you can try turning off twig debug briefly?

Otherwise perhaps you can check what filters you have applied - eg filter auto p, but maybe something else around correcting html/limiting html?

If you are willing to look into the code, you can check the results in $new_text of FootnotesUpgradeBatchManager::processItem() and try to see what is happening..

I checked there is no twig debugging enabled and no other filter than footnote is enabled while the drush convert run.

Do you have any ideas what else I could try?

And with Lorem ipsum[fn]Footnote text[/fn]. Dolor met... you are still getting an extra space after?

I corrected my above comment in the meantime.

The conversation creates an unwanted linebreak, the browser displays a whitespace.

Can you check the actual database values before and after? I unfortunately still cannot reproduce and the tests are showing that with that case, the upgrade script itself correctly changes the database value. This makes me still suspect some sort of filter in your text format.

I have double-checked this by creating a fresh installation of Drupal 10.2 with minimal configuration. No text editor and only the footnotes filter is activated (see attached screenshot)
Unfortunately, the line break always occurs after the conversion. This can be seen in the same way both in the backend on node edit and in the database cell.

Got it! Thanks for bearing with me on it.

I cannot manage to get the tests to reproduce it, but I could do it via the UI with a simple var_dump/die at the end of the ::replaceCallback(). I wonder whether something in core is treating the <footnote> as a block element rather than inline element by default when rendering it, resulting in a new line getting added after it similar to how it would be for example for a <p>. Treating the symptom here rather than the problem, but I think that is fine here given its an upgrade path.

Let me know if that solves it for you as well.

Voilà, now the result of convertion lokks as expected:

Body content:

I am the body text with a footnote followed by punctuation<footnotes data-value="" data-text="Text in footnote"></footnotes>. More text.

Here ist a second example<footnotes data-value="" data-text="Text in footnote"></footnotes> where the text continues.

And the browser output look as expected.

May worth to mention, a additional

within the text does not cause a newline/whitespace to be added.

Thanks for solving this!

Great thanks for confirming!

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