Trim footnotes text via drush command upgrade path from 3.x to 4.x

scott_euser → credited John_B → .

Updated issue summary with details as to how this could be addressed.

Merge request created, test coverage added with example that includes:

1. Multiple line breaks both around and within the footnote text
2. Tabs and spaces around the text
3. Keeping purposeful nbsp (ie, where user adds an intentional non breaking space instead of a space, don't trim that)

@John_B this should cover the drush upgrade command. Anything else you should be able to customise on output in the twig template like |trim and replacing \n\r https://stackoverflow.com/a/26991623 for example.

Thanks.

The latest MR replaces line breaks and so on with tags. There are two problems here:

Problem 1. Footnotes containing <a> or <strong> tags work, but footnotes contaning a <h> tags or <br> or a <br /> or a single or pair of <p> tags or a pair of <ul> tags, and possibly other tags I have not tested, break either the body text or the footnote text in various ways.

In the db log I see
Message Warning: DOMNode::appendChild(): Document Fragment is empty in Drupal\footnotes\Plugin\Filter\FootnotesFilter->process() (line 164 of ~/footnotes/src/Plugin/Filter/FootnotesFilter.php)

Warning: DOMDocumentFragment::appendXML(): ^ in Drupal\footnotes\Plugin\Filter\FootnotesFilter->process() (line 161 of ~/footnotes/src/Plugin/Filter/FootnotesFilter.php)

Also above message with nothing instead of ^. Three is no ^ in my markup.

Warning: DOMDocumentFragment::appendXML(): Entity: line 18: parser error : chunk is not well balanced in Drupal\footnotes\Plugin\Filter\FootnotesFilter->process() (line 161 of ~/footnotes/src/Plugin/Filter/FootnotesFilter.php)

Problem 2. Arguably not a fatal problem, but for a content editor working with complex markup within footnotes, stripping all line breaks, and imposing a rule that no line breaks may be used within the markup, makes the markup diffiult to read and edit.

It is a separate question whether a fault in the markup should be tolerated, or is allowed to break a page using the filter. The toc_api module in D8+ switched to using core's HTML utlility, and started breaking on faulty markup. For now we are still getting problems with correct markup.

To be clear I have not tested the latest MR with --use-data-text=TRUE, only with --use-data-text=FALSE.

Hi @John_B,

Let's please keep separate issues as separate issues - that feels like quite a lot of scope creep here. The issue here is about line breaks and the merge request covers the examples provided as far as I can tell.

If you would like to add support for something else to the drush command, please provide the sample html in a new issue. A quick test adding valid html with unordered list seems to work fine for me. Given you are hand-coding the html, perhaps there are issues with the hand-coding resulting in something invalid that php dom cannot properly read. In that case the options are probably A) fix the html or B) stick to 3.x while you intend to not use CK Editor 5 and upgrade when you are ready to start using it.

As a side note it by the way does really start to seem like you are using footnotes as perhaps call-out boxed text type content and not actually footnotes. Hopefully the code in the MR here provides some hints where you can look in the code so you can contribute the code for your specific cases. Or if others see your issue and turn out to also A) not using CK Editor and B) having complex content instead of citations and references (ie, footnotes) perhaps they are willing to help out as well. Apologies, for being difficult, but please bear in mind I am volunteering my own time.

Thanks,
Scott

Moving back to needs review for review of the issue described in issue summary which I believe the MR accurately covers and automated tests represent the content provided in the issue summary.

The aim of the ticket was to ensure that footnotes which include line breaks work. Using the MR, footnotes containing one or more line breaks do not work either in data-text or inside the <footnotes> tags..

If the purpose of the MR was to make the Drush command convert line breaks to markup, that worked when I tested it. I have not read into the code.

If the purpose of the MR was to make the Drush command convert markup with line breaks to markup without any line breaks, that worked when I tested it. I have not read into the code.

Great thanks for checking. Yes that is the purpose. You have raised a separate issue re rendering like breaks already here 💬 When hand-coding html and line breaks are entered, line breaks are rendered as line breaks by the 'Covert line breaks' filter in core unlike in the 3.x branch Closed: works as designed . Any change to rendering output of line breaks can be made via the twig template which you can pull into your theme but I really do not think that should be the default - it really does seem reasonable to expect that adding line breaks results in line breaks.

I have started a separate issue here for the DOMNode warnings when using eg unordered list 🐛 DOMNode warnings when using more complex html like unordered lists in the footnote reference text Needs review .

Thanks for the details @John_B, there is a merge request available in 🐛 DOMNode warnings when using more complex html like unordered lists in the footnote reference text Needs review .

Will leave this patch here in case others did the same in 3.x and want to fix the root problem, but now we also have ✨ When not using CK Editor and hand-coding footnotes, should "Convert line breaks fiilter" not convert line breaks when within footnotes? Postponed: needs info which suggests to actually change the behaviour so that line breaks within footnotes are ignored in the filter itself for all sites.

So perhaps first the debate needs to be had as to whether line breaks are special compared to other markup and footnotes should:
- respect most html markup
- ignore line breaks

My opinion is that line breaks should be respected within footnotes like any other markup. Let's see what others think.