WebberZone Code Block Highlighting v1.1: Server-Side Highlighting, Theme Parity and more

No two WordPress sites have the same requirements, and I built 1.1.0 around that reality.

Some sites want interactive toolbars with copy-to-clipboard. Others run strict content security policies, track Core Web Vitals scores, or need to keep frontend JavaScript to a minimum. I didn’t want to force everyone into the same approach.

WebberZone Code Block Highlighting 1.1.0 introduces a server-side rendering option alongside the existing Prism.js integration. You can now choose whether syntax highlighting happens in the browser or before the page is sent to the visitor.

Server-side highlighting with highlight.php

Browser-based highlighting works well, but it means shipping Prism.js and its grammar bundles to every page that contains a code block. For some sites, that’s a worthwhile trade-off. For others, it isn’t.

The new rendering mode uses highlight.phpOpens in a new window to generate highlighted markup on the server. By the time the page reaches the browser, the code has already been processed, so no Prism.js or language grammars need to load.

You don’t lose the toolbar either. Copy-to-clipboard, expand/collapse, file titles, and language labels all work in server mode, handled by a small script instead of the full Prism stack.

I built this for sites where every script matters.

The existing browser-based approach remains the default. Switch between modes under Settings > Code Block Highlighting.

Full theme parity across both modes

Changing how code is rendered shouldn’t affect how it looks, and I spent real time making sure it doesn’t.

The obvious implementation would produce different token spans in server mode, breaking the shared theme CSS. To avoid that, I built a token class remapper that converts highlight.php’s hljs-* class names to Prism’s token * class names. The server-side renderer then loads the same theme stylesheets as the browser-based one, giving complete visual parity across all 21 Prism themes.

Switch modes and your code blocks look exactly the same. No re-styling, no surprises.

Plain Text language option

Not every code block contains source code. Configuration snippets, terminal output, log files, and command transcripts often look better presented as plain text, and I’ve added an option for that.

The language picker now includes a Plain Text entry. When selected, the block keeps the active Prism theme styling while skipping syntax highlighting entirely. The best part is that you still get consistent formatting without forcing a language grammar onto content that doesn’t need one.

Bug fixes

I also fixed a duplicate language-* class that could appear on <code> elements when the saved block markup already contained the class.

Upgrading

No action required. Update from your WordPress admin dashboard, and everything continues to work as before. Browser-based rendering remains the default, so nothing changes until you choose to enable server-side highlighting.

Because the plugin extends the native core/code block rather than replacing it, your existing content remains untouched, regardless of the mode you use.

What’s next

I’m watching the support forum closely for feedback on the new rendering mode, particularly around theme compatibility across different hosting environments.

Per-block theme switching is on my radar, but it didn’t make this release. I want the new rendering pipeline working reliably across as many real-world sites as possible before adding more moving parts.

If you run into any issues, post in the support forumOpens in a new window or open an issue on GitHubOpens in a new window.