Possible bug with block identification

[Dreytac]

Hi! I'm using Parsedown as part of Kirby and I think I've found a bug but it may also be intentional.

As an example, I have the following HTML in PHP:

$text = "<table><tr><td>TABLE CELL</td></tr></table><p>PARAGRAPH</p>";

Passing that through as a Kirbytag in Kirby causes Parsedown to strip the entire <p> tag off the end of the string. If I insert a "\n" between the table and paragraph tags, it works as expected.

$text = "<table><tr><td>TABLE CELL</td></tr></table>\n<p>PARAGRAPH</p>";

Swapping the paragraph and table around, causes the table to be completely removed instead. I've narrowed it down to the lines() function doing it but that's as far as I can get as I get lost in the code. I hope you can understand the issue I'm having. It took me a couple of hours to work out where the problem was.

[aidantwoods]

I think this is actually an issue in ParsedownExtra rather than Parsedown, perhaps you can confirm you're in-fact using that?

Assuming that's correct it looks like the issue is in processTag, in which ParsedownExtra only considers the first tag and it's contents (in this case <table>).
E.g. if you input <p></p><a></a> then ParsedownExtra will output <p></p>.

I've kind of considered processTag to already be on the chopping block for the next version since it is taking on far too much responsibility in having to parse HTML (and doing so incorrectly yields bugs like this). The reason that it's there is to facilitate the markdown=1 attribute for allowing markdown to be parsed within HTML—though the CommonMark solution for embedding parsed markdown within raw HTML is superior IMO, and I think the correct solution to this problem is just to remove this special handling at the first opportunity (i.e. the next version).

[Dreytac]

I can confirm that by disabling ParsedownExtra, you are right and the problem goes away. I don't think I currently use any ParsedownExtra features at the moment so I will leave it disabled for now.