Snippet Code is re-rendering as HTML at save

Further update!

I was curious as to whether one of our specific Snippets — which worked perfectly before, and that modified the Admin Editor page for our contributors — might be causing or part of the problem.

I want to emphasize that all had been working perfectly UNTIL the latest WP Code update. So, it’s not like a snippet we just wrote caused the problem. But, rather, something that changed there conflicted with something we already had in place here.

I asked Claude to look at that Admin Editor snippet and he saw what COULD be part of the problem. We made a change to it, and it fixed the display issue on SOME snippets (the simplest ones that were PHP only). But the more complex ones with mixed PHP, CSS, JS etc. were still garbled.

I then asked Claude to put together a more fullsome explanation of all of that that would hopefully be more helpful on your end. Here’s what he put together for us:

Bug Report for WPCode Support/Developers

Summary: After updating WPCode to the latest version this past weekend, our snippet editor began displaying garbled/malformed HTML markup wrapped around our PHP snippet content (e.g., snippet code appearing wrapped in stray <p>, <li>, <blockquote> tags, with <, >, & HTML-entity-encoded). The underlying saved PHP is not corrupted — retrieving it via other means (e.g., pasting the “garbled” display text back to a text parser) confirms the actual code is intact; this is purely a display/rendering bug in the snippet editor itself.

What we ruled out (and how):

We initially suspected one of our own custom snippets — “BB WP Admin Editor Tools” — might be contributing, since it applies CSS overrides and JS to any WordPress post/post-new admin screen, and we realized WPCode’s own snippet-edit screen also registers as $screen->base === 'post' under the hood (since WPCode snippets are a custom post type using the same post.php admin page). That meant our snippet’s CodeMirror CSS overrides (forcing light theme, hiding line numbers/gear icon, custom syntax colors) and our admin_footer JS (Quicktags buttons, keyboard shortcuts) were very likely firing unintentionally on WPCode’s own snippet editor, not just our actual WordPress Post/Page editors.

Our fix: We added a $screen->post_type check (in addition to the existing $screen->base check) so our overrides only fire when post_type is post or page — explicitly excluding WPCode’s snippet post type. Example of the change:

php

// BEFORE:
add_action( 'admin_head', function() {
    $screen = get_current_screen();
    if ( ! $screen || ! in_array( $screen->base, array( 'post', 'post-new' ) ) ) return;
    // ... CodeMirror CSS overrides ...
} );

// AFTER:
add_action( 'admin_head', function() {
    $screen = get_current_screen();
    if ( ! $screen || ! in_array( $screen->base, array( 'post', 'post-new' ) ) || ! in_array( $screen->post_type, array( 'post', 'page' ) ) ) return;
    // ... CodeMirror CSS overrides ...
} );

Result of our fix: This resolved the garbling on a simple, PHP-only snippet (our “BB WP Admin Editor Tools” snippet itself) — it now displays cleanly in the WPCode editor. However, it did not resolve the garbling on a separate, much larger snippet of ours (“BB Media Player Tool”) that mixes PHP with embedded HTML, <style> blocks, and <script> blocks, deeply nested with ob_start() output buffering and PHP short-echo tags inside HTML attributes. That snippet still displays with the same garbling symptoms even with our conflicting CSS/JS now properly scoped away from your editor screen.

What this suggests: The remaining bug appears to be content-dependent — specifically correlated with snippet complexity/size and the mix of PHP + HTML + CSS + JS in a single snippet, rather than caused by any conflicting admin CSS on our end.

Possible lead: Your recent changelog entry — “Tweak: You can now resize the code editor on the Live CSS Preview screen by dragging the divider between it and the preview, and it remembers the size you set” — introduces new resize-handling JS wired to the CodeMirror instance. It’s plausible that resize/refresh logic (e.g., recalculating line-wrapping, re-tokenizing visible content, or re-initializing the editor’s rendering on resize) behaves correctly on small/simple snippets but hits an edge case on large snippets with deeply mixed PHP/HTML/CSS/JS content — which would explain why our simple PHP-only snippet now renders fine while our large mixed-content snippet doesn’t.

Suggested reproduction steps for your team:

1. Create a WPCode PHP snippet containing multiple nested PHP functions that each echo or output-buffer large blocks of HTML, including inline <style> and <script> tags with their own nested quotes/brackets (i.e., a snippet in the 300+ line range mixing all four languages).
2. Open it in the WPCode snippet editor.
3. Observe whether the display renders correctly on load, then re-renders with stray HTML tags wrapped around the code and HTML entities in place of </>/& shortly after — this “renders correctly for a moment, then corrupts” behavior is what we’re seeing.
4. Compare against a simple, PHP-only snippet of similar total length but without embedded HTML/CSS/JS, to see if the simple one is unaffected.

We’re happy to provide the exact snippet content privately if it would help you reproduce this.