Sometimes, you want to code the <p>...</p> yourself, because you need to add a class or another attribute to the <p>.
Consider the following valid HTML:
<blockquote class="quote"><p>“The remedy for what ails our democracy is not simply better education (as important as that is) or civic education (as important as that can be), but the reestablishment of a genuine democratic discourse in which individuals can participate in a meaningful way – a conversation of democracy in which meritorious ideas and opinions from individuals do, in fact, evoke a meaningful response.”</p>
<p class="author">Al Gore, The Assault on Reason</p>
</blockquote>
The Drupal filter will add a superfluous </p> just before the <blockquote>:
<blockquote class="quote"><p>“The remedy for what ails our democracy is not simply better education (as important as that is) or civic education (as important as that can be), but the reestablishment of a genuine democratic discourse in which individuals can participate in a meaningful way – a conversation of democracy in which meritorious ideas and opinions from individuals do, in fact, evoke a meaningful response.”</p>
<p class="author">Al Gore, The Assault on Reason</p>
</p></blockquote>
The same happens if we put the <blockquote> on the same line as the last </p>.
The temporary fix is NOT to write the last </p> since Drupal will add one.
But
1) it forces the user to enter invalid html
2) when this bug gets fixed, all such nodes would have to be updated again to fix this.
Tested on latest HEAD code (Drupal 6).
Comments
Comment #1
beginner commentedThe problem is in function _filter_autop($text).
When I comment out this line, the problem disappears:
To reproduce:
The code in question is unchanged between D5 and D6, so you can test with either.
Create a node, select the 'php' input format, and insert the following code in the node:
comment and uncomment the said php line, and see the difference.
Comment #2
beginner commentedSee this chunck of code:
We start with the following text:
The closing blockquote can be on a separate line or at the end of the previous line. It doesn't seem to matter.
Before the troublemaking line is executed, we text has become thus:
I.e. plenty of
<p>'s and</p>'s have been added.The troublemaker changes the text to:
I.e. it prepares the ground for the rest of the of the code to remove the redundant p's.
The problem is that in this situation, the current code misses one /p, thus:
Rather than removing the troublemaking line which must be there for a reason, we add a str_replace() to remove code that is bound to be useless in every circumstances.
The added line removes the empty pair of
<p></p>and solves the problem.Comment #3
dries commentedRemoving the blockquote line doesn't seem to be an option; it would render the generated HTML code invalid as the paragraph and blockquote tags would be unbalanced.
The line that you added in #2 already exists higher up (only slightly more generic):
$chunk = preg_replace('|<p>\s*</p>\n|', '', $chunk); // under certain strange conditions it could create a P of entirely whitespaceWould it be sane to move that line down?
Either way, even if you move that line down, the generated HTML code is sub-optimal -- or am I wrong?
It's not quite clear why blockquote needs special treatment. I'm left wondering if we could remove both:
Comment #4
beginner commentedI tried moving the more generic line down to where I added the new line as you suggested, but it doesn't work. I still end up with the extraneous /p.
I don't know what you mean by the generated HTML code being sub-optimal . Without the patch I have invalid html but with it the html validates.
The blockquote lines must be there for a reason. It would be foolhardy to remove them and expect no to break anything. Actually, they seem to be here to ensure that p's are nested within blockquote and not the other way around.
<p><blockquote></blockquote></p>is not valid.Having tried some more, I can state:
1) the patch fixes a validation bug.
2) the patch is so simple (removing an empty paragraph) that it cannot break anything else.
The only question in my mind is: is it worth to add a comment, with a reference to this issue?
Comment #5
beginner commented- the patch is trivial
- it can't possibly break anything
- it fixes a bug
- alternative methods suggested have more chances to break something. Anyway: they have been tried but they failed.
Ergo: RTBC.
Comment #6
gábor hojtsyPlease do not RTBC your own patches. Get this reviewed and tested by a few people. Automated filter correction is not a trivial thing for sure, so this needs to be tested in some use cases.
Comment #7
beginner commentedIt is said in many places and by many people that in case of a very trivial patch, it is ok to RTBC one's own patch.
The rest of your comment also strongly suggests that you didn't even have a look at the patch :-/
Comment #8
gábor hojtsyI did look at the patch, but reading what Dries had to say, it does not seem to be right to RTBC this without a wider review in the community. As I said, automated HTML filtering is a tricky thing.
Comment #9
beginner commented1) I replied to Dries's concerns.
2) how tricky can removing an empty paragraph (
<p></p>) be??Comment #10
chx commentedbeginner, are you sure that removing
is harmless? I do not know, for example, can't the user enter that for CSS purposes?
Comment #11
beginner commentedThe patch only removed a completely empty
<p></p>.If someone uses an empty P for CSS purposes, then adding a space would do the trick:
<p> </p>.Does this mean that for this one liner to get committed, we need to create an upgrade function system_update_7009(), searching the DB for
<p></p>and replacing all instances with<p> </p>?Comment #12
robin monks commentedI know I have added empty paragraphs to my posts before. -1 for this solution.
Robin
Comment #13
catchI think this is won't fix. Or at least it should come with a test.
Comment #14
beginner commentedI don't see why a real bug should be won't fixed.
Comment #15
catchSorry, I should've read further up the issue, the extra
</p>is indeed an issue. However I'd rather see if we can't get rid of the unclosed tag, rather than changing the behaviour of the filter as in the current patch. Another option would be for the htmlcorrector filter to handle extraneous closing tags more generally (afaik it only cleans unclosed tags).Comment #16
dries commentedIt looks like this might be a duplicate of #212236: Automatic line breaking sometimes results in an unpaired end of paragraph tag which I'm about to commit to CVS HEAD. Please confirm, and update the status accordingly. Thanks.
Comment #17
catchI'm pretty sure this bug was fixed today by #212236: Automatic line breaking sometimes results in an unpaired end of paragraph tag but if someone could confirm this would be great before marking it as duplicate.
Comment #18
catchMissed Dries' post which says the same thing. Leaving status as is though.
Comment #19
wrwrwr commentedTested the example from the description and it validates for me with Drupal 5, 6 & 7 now (with #212236 patches applied).
Comment #20
damien tournoud commentedLet's conclude that this is a duplicate #212236: Automatic line breaking sometimes results in an unpaired end of paragraph tag.