automatic conversion of html entities after reloading the page in the editor

[GitHub-Mike]

The used html entities (curly braces) are automatically converted to "normal" characters after reloading the page in the editor.
Tested in code and paragraph block.

1. Go to 'hello world'
2. Click on 'edit'
3. insert '&#123text&tinymce-single: add toolbar styles from main prototype #125' (code or visual view)
4. save changes
5. view page
6. edit page
7. new text is: '{text}'

No automatic conversion of html entities after opening or editing the content in the editor.

A solution via a filter hook would certainly be useful and could cause an optional global deactivation of the conversion.

• WIN10
• Chrome
• 74.0.3729.169
• WordPress 5.2.1–de_DE

[draganescu]

Hi @GitHub-Mike,

This looks like an inconsistent behaviour:

• pasting {text{ in visual or text mode replaces HTML entities on blur or on save + reload, but not on save alone, causing bad UX
• pasting an incorrect {text&#123 (no semicolon at the end) replaces the 1st HTML entity and when correcting the second one it doesn't get replaced.

We need to see if it is possible to not replace HTML entities at all or at least if we do to do it consistently.

Note: the classic editor is even more unpredictable, pasting &#123text&#125 results in {}, the word text is gone and it converts the entities even though they are malformed (missing semicolon).

[GitHub-Mike]

Hi @draganescu,

The semicolon was only forgotten when creating this post, but not in the code of the editor! (I should have formatted it as code here, otherwise the curly braces will be converted here as well)

Yes, the conversion happens by the way when switching from the text to the visual view.

It would be nice if there would be a way to disable the automatic conversion completely.

Later you could restrict this to certain entities.

[youknowriad]

The main reason here is that when parsing a block that relies on html sourced attributes, hpq (our parser library) uses element.innerHTML to extract the HTML from the block attribute (inserting the HTML into a random element and extracting the bits we need), browsers though automatically convert HTML entities in their DOM APIs.

So a potential solution would be to avoid using the browser APIs to parse the block attributes, but I don't know exactly if there's an alternative there that doesn't involve writing a custom HTML parser (which sounds too heavy for the issue at hand both in terms of maintainability and performance).