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.
| Comment | File | Size | Author |
|---|---|---|---|
| paragraph.within.footnotes.diff.txt | 1.99 KB | beginner |
Comments
Comment #1
beginner commentedIn 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...
Comment #2
beginner commentedComment #3
hingo commentedHi 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
Or I can just paste it here so everyone can see how it breaks down:
with line breaks in between?
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:
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.
Comment #4
hingo commentedI created a bug for filter.module about this issue here.