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

  • Resolved dar12

    (@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.

    Thanks!

    • This topic was modified 3 months ago by  dar12.
    • This topic was modified 3 months ago by  dar12.
Viewing 7 replies - 1 through 7 (of 7 total)
  • Plugin Author James Bradford

    (@arniebradfo)

    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?

    dar12

    (@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.

    Thanks!

    dar12

    (@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.

    https://github.com/WordPress/gutenberg/issues/11211

    https://core.trac.wordpress.org/ticket/45636?cversion=0&cnum_hist=1

    https://wordpress.org/support/topic/gutenberg-does-not-play-nicely-with-code-editor/

    Plugin Author James Bradford

    (@arniebradfo)

    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.

    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

    (@arniebradfo)

    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.

    Thanks

Viewing 7 replies - 1 through 7 (of 7 total)
  • You must be logged in to reply to this topic.