Markdown module regression in support for multiple codeblocks in same document

[mqudsi]

Impacted plugin

Jetpack

Quick summary

At some point, the markdown module in the Jetpack plugin broke its handling of multiple consecutive code blocks consisting of ``` in \<pre> tags, lumping together the non-contiguous blocks instead of treating them separately.

Example of correct behavior before (reproducible now only by disabling the markdown plugin in Jetpack):

Versus how it is rendered now after enabling markdown support then updating the post (under 13.1.1):

This may or may not have been a regression introduced after 12.9.3 (which is the version I upgraded from, but it's hard to say because I don't know if I saved the post under 12.9.3 or not).

Steps to reproduce

You can reproduce the bug by creating a post with the contents of this article: article.txt

A clear and concise description of what you expected to happen.

Separate code blocks should be rendered, using the \<pre> tags, not the ``` within it.

What actually happened

The opening \<pre> tag continues past the ending \</pre> tag.

Impact

One

Available workarounds?

No and the platform is unusable

Platform (Simple and/or Atomic)

Self-hosted

Logs or notes

No response

[jeherve]

I can reproduce the problem on my end. I'm not sure when it was introduced, though. I've tried reverting all the changes we've made to the Markdown feature in the last 3 years, and the problem remained.

Are you able to track back a point when you published a post and the bug didn't exist? If so, could you give me the exact date? That may help me narrow things down a bit.

[anomiex]

I also was unable to find a version of Jetpack where the markdown you supplied does not result in the incorrect rendering.

On the other hand, if I change everywhere in your document where you have

<pre>```something

to

<pre>
```something

(i.e. put the <pre> on a line by itself) it seems to render as you intend.

[mqudsi]

Thanks for finding that.

Ok that explains it - I always type it in manually on separate lines but there is a longstanding bug in the pipeline that “arbitrarily“ eats the opening new line after an opening pre tag either when saving or when switching between GUI and HTML views. That would explain why I didn’t run into this on publish but see it now on edit (with what happens to be a newer JP version).

Presumably the regex (I’m guessing that’s what it is based off the behavior) should still be updated to handle the submitted test case?

[jeherve]

Presumably the regex (I’m guessing that’s what it is based off the behavior) should still be updated to handle the submitted test case?

We could give it a try, but I'm not sure we should support that use-case. Fenced code block markers should always be on their own line, as far as I know.

Maybe we should aim to understand that bug instead?

there is a longstanding bug in the pipeline that “arbitrarily“ eats the opening new line after an opening pre tag either when saving or when switching between GUI and HTML views.

In general I would recommend against using the Visual editor when you type in HTML in the editor view, but saving should not mess your layout ideally.

Is there any chance you could provide us with steps to reproduce this? I tried the following, but no luck:

• Go to Posts > Add New
• Switch to the Text view
• Type in some sample text with markdown and HTML, like in your example.
  • In there, include some fenced code blocks wrapped in <pre> tags, on their own line.
• Hit Publish
• Close the editor
• Open it again, make some changes, hit Update

At this point the tags remained on their own line in my test, so I must be missing a step I think.

[github-actions[bot]]

This issue has been marked as stale. This happened because:

• It has been inactive for the past 6 months.
• It hasn’t been labeled `[Pri] BLOCKER`, `[Pri] High`, `[Type] Feature Request`, `[Type] Enhancement`, `[Type] Janitorial`, `Good For Community`, `[Type] Good First Bug`, etc.

No further action is needed. But it's worth checking if this ticket has clear reproduction steps and it is still reproducible. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation.