Support » Plugin: HTML Editor Syntax Highlighter » tags being stripped in classic block content after WP upgrade

  • Resolved dar12


    Today I upgraded from WP 4.8 to WP 5.0.3. Also updated HTML Editor Syntax Highlighter plugin to latest 2.3.1 version (I am not using the classic editor plugin). My prior page content had all been created via prior version (as far back as version 1.7) of this HTML editor plugin under WP 4.6 & 4.8. In the WP upgrade, the page content was automatically converted over to Gutenberg by placing all the content into a single Classic block (as expected, I guess). When setting Gutenberg to “code editor” this plugin kicks in and generally seems to work, but with some glaring problems, as follows:

    When attempting to edit the carried over content in the classic block, some tag types, like the p tag, do not show in the editor, and if I enter them they disappear when saving (both opening and closing tags get stripped from display whether there is content in the p tag or not).. However the p tags do show up when I switch over to the standard Gutenberg visual editor and display via the HTML view (and I confirmed via browser inspector that the tags are in fact there in the published code). The p tags do also show (don’t get stripped from display) if they contain any properties. Also noticed that line break tags were getting stripped or not showing and converted into an empty pair of p tags…. br tags do show on the standard Gutenberg HTML editor. So, all the carried over html would display OK in the Gutenberg visual html view, but not when switching to the plugin/”code editor” mode.

    I did some experimenting and found that if the original classic block containing the legacy content is on the page by itself, the above problems exist, however if I use the Gutenberg visual editor to add a different block type, like an empty html block at teh bottom of the page, then the existing p tags in the original classic block content suddenly show up OK and can p tags can also then be added and saved without being stripped. Somehow, by using the new block types in addition to the classic, the tags in the original classic block display correctly, or at least more correctly…

    I’ve seen some other articles about other editor plugins having similar problems, but have not seen anyone commenting on such an issue for this particular plugin.

    Is this a known issue with any solutions known?

    UPDATE: I installed the “Classic Editor” Plugin and the same problems occur in the classic text editing mode using same updated config described above: existing p tags and br tags are not visible, and disappear when saving page after adding them, even though they actually exist in the code. Prior to the WP and html editor updates mentioned above, everything was fine, no tags were ever stripped from the display.


    • This topic was modified 5 years, 1 month ago by dar12.
    • This topic was modified 5 years, 1 month ago by dar12.
Viewing 11 replies - 1 through 11 (of 11 total)
  • Plugin Author James Bradford


    I think I can help you.

    However, this plugin is probably not whats causing the issue you’re facing. The addition of <p> tags and formatting is a native wordpress feature. This plugin does not edit or filter the content of your posts. It only highlights the code.

    wp auto p
    Wordpress has a feature called the “auto p” filter which

    Changes double line-breaks in the text into HTML paragraphs.

    For example, auto p will take some standard post content like this:

    Some long text
    that has many lines
    and paragraphs in it.

    and turn it into this:

    <p>Some long text<br/>
    that has many lines</p>
    <p>and paragraphs in it.</p>

    Like your little brother, it thinks it’s helping, even if it isn’t.

    What to do about it
    There are several plugins you can use to disable it in the Classic Editor. I’d recommend Toggle wpautop. As for Gutenberg, it looks as though there is a new autop feature that is run with javascript. I’m not sure how you could disable it easily, but there does seem to be a “removep” that does the opposite.

    I hope you’re a little more informed about whats going on with your content. This issue is beyond the scope of this plugin. Also, I’m willing to bet you’d still have this issue if you deactivated this plugin.

    Does this sound about right?

    Thread Starter dar12


    James — thanks for the reply (received it via email, and for some strange reason your reply took 30 minutes to show up in this thread later even though your reply registered immediately in the numeric stats — strange — Now after 30 minutes, your reply is finally showing)

    With regard to your comments:

    – I’ve been using this functions.php filter for years to stop the auto insertion of p tags by the editor ( remove_filter(‘the_content’, ‘wpautop’); ) and I’ve tried this now with and without and it makes no difference in 5.0.3

    – I think, as you mentioned, the real problem is the apparently new “remove p” action that’s taking place for some strange reason. As I said originally, p tags that are in my content html, which were placed by me originally via your plugin in WP 4.X, are being removed from the “code editor” view in Gutenberg (but the p tags are really still there, they just aren’t displayed). And yes, to your point, when I deactivate your plugin, the p tags are still not showing in the native Gutenberg “code editor” mode.

    – When switching back to the “visual editor” in Gutenberg, and then looking at the block using the “edit in HTML setting”, the actual HTML displays correctly, including the p tags that are missing in the “code editor” view.

    – Interestingly, when I activate the “Classic Editor” plugin, if in visual editor mode before going to the text/html view, the p tags are also stripped in that case! So, simply going to Classic Editor does not fix the problem — the “remove p” phenonmenon still occurs, seemingly as a designed-in “feature” of the visual editor — why would they do this?? If however, I go into my user profile and click to disable visual editor, then the html view works correctly with nothing being stripped, so this seems like further proof it’s the gutenberg visual editor that’s doing the stripping somehow. In past years, in WP 4.x while I used your plugin for all my page editing in html, I had this “disable visual editor” setting checked to prevent any interference from the visual editor and everything was fine…
    Unfortunately, with that disable setting set now in Gutenberg, your plugin does not run at all, because apparently the “visual editor” mode needs to be active to support the “code editor” functionality — also weird.

    – I did find work arounds that seems to work, at least to some degree: (Remember, this problem exists with the html page code that was automatically placed into one big classic block in the upgrade process from 4.X to 5.0.2
    Workaround #1: if I add a new standard block, even if its empty, to the page while in visual editor, somehow that makes the code editor NOT strip the p tags in the classic block, and seems to then show everything correctly.
    Workaround #2: If I copy the correct html code display from the “edit in html” view while in the visual editor for the classic block, and then paste that into a new “custom html” standard block (and then delete the original classic block), the code editor, and your plugin, seem to show everything correctly from the html block, with nothing being stripped.. SO, it seems this odd stripping only occurs on content of the classic block that was created during the WP upgrade to 5.0.3

    Unless you know how to turn off the new, undesired “remove p” behavior of gutenberg that strips p tags from classic blocks in the code editor (incorrectly so in my opinion), I seem to have no choice but to use one of these workarounds.

    I guess my real question at this point, for those of us that do most of our content development and editing work at the “custom” html level, why am I the only one talking about this… it seems to be behavior that the WP community has rationalized as a feature (I see it as a major bug), but God knows why anyone would want this behavior?! It literally prevents a person from having true control of their html in the so-called “code editor” mode.

    With that additional info, please advise on any other thoughts that might help me here. As with many developers, I have tons of legacy content that I need to maintain at the HTML level that is subject to this issue.


    Thread Starter dar12


    Additional references:

    I came across these 3 threads that discuss similar issues in the code editor (not related to this plugin, but to the Gutenberg code editor mode in general, which does/could impact the utility of this plugin). None of these threads result in any solutions, but do show the frustration and lack of understanding by others not living in the html world

    The first thread below is the most relevant to my issue, note this quote “From what I can tell, Gutenberg deletes ALL paragraph tags from “Classic” posts… unless they have been styled with inline CSS… if you make any changes in the editor.”

    Again, my observation is that the p tags are not actually being stripped (they do show up in the visual editor in html edit mode, and they do show up in the published code, it’s just a matter of them not showing up in the code editor display, thereby making html editing in the code editor sort of a worthless endeavor without some sort of workaround like a mentioned earlier.

    Plugin Author James Bradford


    Thank you for your very detailed report of the remove/auto-p functionality in Gutenberg. It will help me in trying to support Gutenberg in the future.

    Stopping the removep feature may also be possible, but a solution might be hacky and weird. I will look into it.

    Unfortunately, with [“disable visual editor”] disable setting set now in Gutenberg, your plugin does not run at all, because apparently the “visual editor” mode needs to be active to support the “code editor” functionality

    This might be something I can fix more near-term.

    Thread Starter dar12


    Thanks, I look forward to any fixes related to this. Do you have any insight as to why the “removep” behavior is there in the first place? If intentional, there must be some logic behind it, as poorly conceived as it might be, but I have no clue why such p-tag stripping from the code editor would be desirable in any scenario.

    Plugin Author James Bradford


    Addressed in the FAQ now:
    Why are p a br tags being removed?

    Hi James,

    I hope a fix is found for this bug soon as it is very annoying.




    I’m also waiting on a solution for this issue. I prefer to see *all* the html code in the code editor. I don’t see the point to stripping <p> </p> tags that aren’t styled with inline css.

    Just discovered that probably both classic and gutenberg blocks look for “sections” (section tags) correctly formatted to keep the p tags.

    some of my code had “a” and “p” tags within divs with no classes or ids so the issue happened; but when I changed divs for sections and wrapped “a” with “h”, p tags reappeared.

    • This reply was modified 4 years, 9 months ago by darkseiryoku.

    After upgrading from WordPress 3.x to 5.x, when creating a new page (by default a page using Blocks), pasting text into this blocks view, selecting the text all and copying it and then adding a “Classic” editor block and pasting the content now there instead, I had the following problem:

    p tags showed up the visual editor and the “Edit as HTML” editor view. However, they do not show up in the published code.

    The solution I found to this was to carefully prune through the “Edit as HTML” editor view removing any classes adding to the p tags e.g.

    <p class="something">text</p> to <p>text</p>


    Removing empty p tags, especially ones with the following WP line comment:

    <p><!-- /wp:paragraph --> <!-- wp:paragraph --></p>

    Once I removed these and saved, my p tags started showing up in the published code.

    After that you’re free to use the Classic HTML or visual editor for your content.

    I recently upgraded to WP 5.2.3, plus upgraded a number of plugins. Following the upgrade I noticed that the formatting on a number of Posts and Pages was wrong. All the paragraphs on these pages had lost their styling. The reason: the <p> tags had been stripped somewhere between page/post extraction and publication.

    The <p> tags are there in the original text. If I edit the pages/posts and switch to HTML, then they are clearly visible. The problem does not impact every page, but appears to be restricted to those where I had switched from Gutenberg Editor back to Classic Editor.

    For myself I did stumble across a solution:
    Switched back to Gutenberg Editor
    I edited the page.
    Switched to HTML text
    Copied the complete text.
    Deleted the text AND its containing block – so that I was back with an empty page in Gutenberg.
    Pasted in the text.

    So, that’s a solution that has worked for me.

    Note: I do not believe this problem is related to the wp_autop function, which, as I understand it, is designed to interpret two consecutivde blank lines to mean ‘Start a new Paragraph’. This problem is the removal of all <p> tags and the consequent loss of styling associated with the <p> element. I am not sure what the reasoning is behind the <p> tag removal, and the FAQ page referenced above does not actually explain the reasoning, but I would respectfully suggest that any code that decides it knows what HTML restructuring to perform is entering an area it should not.

Viewing 11 replies - 1 through 11 (of 11 total)
  • The topic ‘tags being stripped in classic block content after WP upgrade’ is closed to new replies.