If footnotes <fn> is used together with Line break converter, then we have xhtml validation errors if the footnote contains line breaks. The first opening <p> and the last closing </p> are missing within the list of footnotes <li></li>.

The easiest fix is by letting the Line break converter do its job BEFORE footnotes <fn> then by running a simple check to clean the mess.

the code below removes all properly formatted paragraphs, including user input by users (which may contain classes, id, etc.):

$test_p = preg_replace('/<p(.*)<\/p>/', '', $store_matches[ $m - 1 ]);

the two if statements below that look for remaining <p> or </p> that would be the signature of the current problem, and closes/opens the tag appropriately.

The patch also documents the new requirement in README.

To avoid some overhead in input formats which don't use Line break converter, a check could be added to check if it is being used for the current node. The patch doesn't include this check.

CommentFileSizeAuthor
paragraph.within.footnotes.diff.txt1.99 KBbeginner

Comments

beginner’s picture

In case you are curious, this is the page with a single large footnote where we found the problem:

http://www.reuniting.info/science/oxytocin_heals_cravings_for_sweets_dav...

beginner’s picture

Status: Active » Needs review
hingo’s picture

Hi beginner. I've been traveling on holidays, but am now spending a day fixing my own site and also paying attention to this.

The patch as such is ok, but the bug is not so much in footnotes as it is in the line break converter. The lbc filter does not handle lists very well it seems, try this

<ol>
<li>Ok, so isn't this an issue with line break converter anyway?</li>
<li>What if I have just an ordinary list

with line breaks in between?</li>
<li>It's not gonna work then either
is it?</li>
</ol>

Or I can just paste it here so everyone can see how it breaks down:

  1. Ok, so isn't this an issue with line break converter anyway?
  2. What if I have just an ordinary list

    with line breaks in between?

  3. It's not gonna work then either
    is it?

So as a result, I'm not gonna accept this patch, it is the lbc filter that should be fixed. (I will run into this myself at some point too, so I'm glad you found the issue, nothing against that.)

About ordering: As a rule of thumb, footnotes should always be before any filter that does any kind of html manipulation and that includes lbc filter. Things would work out ok if:

  1. footnotes are handled first, producing the ordered list at the end
  2. line break converter can handle lists (li elements) that include line breaks

On the other hand, I would not necessarily expect things to work with lbc filter first, even with the bug fixed. This is because when processing filters, in the point after lbc but before footnotes, the text would temporarily contain p-elements within another p-element, which clearly isn't valid html and I would not expect line break converter to produce such output.

hingo’s picture

Status: Needs review » Closed (won't fix)

I created a bug for filter.module about this issue here.