Upgrading to WordPress 5 breaks shortcodes

[jacobweber]

Using Wordpress 4.9.10 and SyntaxHighlighter Evolved 3.5.4, I created a page, and put the following content into the Text editor:

[php]
<?php
  function foo() {
    $bar = 1;
  }
?>
[/php]

[xml]
<foo>
  <bar></bar>
</foo>
[/xml]

When published, it displays with the correct highlighting and indentation:

(I know I'm correct to not HTML-encode this content in the editor, because if I do, it displays incorrectly when published.)

Then I upgraded to WordPress 5.4.2. After the upgrade, the page initially displays correctly.

However, when I try to edit it, it adds an extra layer of HTML-encoding to the content. When I go to Edit Page, it opens as a Classic block, and looks like this:

And when published, it looks like this:

What's worse, every time I CLICK inside the block editor and then click outside it, it adds another layer of HTML encoding:

And when published, it looks like this:

Is there any way to salvage this content when upgrading?

[alexsanford]

Thank you very much for the report. I'm seeing the same thing. And when I click into the block and back out, it adds an extra layer of encoding every time.

Note that this also happens on WordPress 5 if the Classic Editor plugin is activated, the above code is added to a post, and then the Classic Editor is deactivated.

[jaredatch]

We're still running into this with WP 5.4 with Classic Editor.

[merkushin]

I was trying to reproduce the problem with WordPress 5 and Classic Editor.

When I added the example code from the issue to the Text tab of the Classic Editor and saved it, it looked correct in the Text tab of the editor and in the post preview.

When I deactivated Classic Editor, I got encoded entities both in Visual Editor and in Code Editor.

However, I found that it is just a difference in the output of editors. In the database, we see encoded entities for both editors.

At the moment, it doesn't add new encoded entities unless you try to switch editors in Visual and Code mode back and forth. But this is expected behavior.

To summarize my findings:

• Classic Editor’s version has < & > in DB. But it appears in the editor like normal HTML with < & >.
• The Block editor gets content and outputs it as is: that means with encoded signs.
• If we replace these entities in the Block editor:
  • it will be stored as-is (as tags) in DB until it is a PHP tag <?php or ?>
  • PHP tags become comments: <--?php and ?-->

It looks like I reproduced the main part from the issue. At the same time, I feel like it works as it should.

We can't just decode entities when we didn't encode them. It might break the code created previously.

It looks like we might want to process the text of posts when we deactivate Classic Editor. But that won't work with upgrading WordPress from version 4 to version 5. At the same time, the problem with PHP tags looks unsolvable with non-encoded entities.