Fenced code: Some combinations of newlines and closing php tag do not html-escape characters

[asartalo]

The following text will render okay:

```php
<?php
// some code
$foo->bar();
?>

But this doesn't:

<?php
// some code

$foo->bar();
?>

And produce this unescaped output

``` html
<pre><code class="language-php"><?php
// some code

$foo->bar();
?>
</code></pre>

[egil]

This is definitely a security problem that needs fixing. Thanks for pointing this out. Cheers, Egil.

[ziz]

This appears to be related to an inconvenient overlap between the Markdown Extra and Markdown Extended parsers and backtick-fenced code blocks versus backtick-enclosed code spans. We've made a change (crowdfavorite/php-markdown-extra-extended@92612c0) that I believe addresses the behavior properly in Extended mode while leaving the Extra mode parsing untouched, and I cannot at this time speak to the proper behavior of Extra in similar situations.

[metude]

I think issue still remains. If render below in Markdown Extended parser it returns empty.

<?php $time = microtime(); $time = explode(' ', $time); $time = $time[1] + $time[0]; $finish = $time; $total_time = round(($finish - $start), 4); echo 'Page generated in '.$total_time.' seconds.'; ?>

In DOM above code comes with comment line;

<!--?php
$time = microtime();
$time = explode(' ', $time);
$time = $time[1] + $time[0];
$start = $time;
?-->

[clphillips]

This is definitely still an issue.

[egil]

I do not have any free time to contribute to this project the foreseeable future. If anybody can contribute a fix I will be happy to merge it into the project.

[nazar-pc]

This bug is solved in my fork: PHP Markdown Next Actually, solution is simple: in _hashHTMLBlocks_inMarkdown method, "Check for: Code span marker", replace

$tag[0] == '`'

by

$tag[0] == '`' && $tag[1] !== '`'

[clphillips]

@nazar-pc With your fix, instead of:

<pre><code class="language-php">&lt;?php
echo "hello world";
?&gt;
</code></pre>

I get:

<pre><code class="language-php"><!--?php
echo "hello world";
?-->
</code></pre>

Looks like unwarranted comment blocks, as @metude pointed out, is still an issue.

[nazar-pc]

Sorry, looks like I have another realization of doFencedCodeBlocks method. Try my parser, it doesn't differ much from this one, but works correctly and a little bit faster. If you need this parser - look at doFencedCodeBlocks method from my fork for the solution.

[clphillips]

Thanks @nazar-pc will checkout your fork.