Why Most WordPress Syntax Highlighting Plugins Replace the Code Block (and Why That’s a Problem)
Most syntax highlighting plugins for WordPress register their own block instead of working with the native core/code block. That works as long as the plugin stays installed. The moment you want to leave, every code block on your site is tied to a plugin you can’t remove cleanly.
I wanted syntax highlighting without giving up the core Code block. The plugin I used was deprecated, and most alternatives registered their own block. So I built WebberZone Code Block Highlighting.

The block replacement problem
When a plugin registers its own code block, your code lives inside that block. The editor can only work with it while the plugin is active.
Deactivate it and WordPress no longer recognizes the block. Each one becomes a notice saying your site doesn’t support it, with options to leave it, convert it to Custom HTML or remove it. None of them gives you a Code block back.
Switching to another highlighting plugin means the same migration. Across a site with hundreds of code examples, that’s a real headache.
Extend, don’t replace
WebberZone Code Block Highlighting uses block filters to extend core/code. Every code block stays a Code block, with or without the plugin.
Deactivate the plugin and the highlighting goes away. Your code stays in the post and still displays on the front end.
The editor needs one extra step. Blocks with a language, file name, highlighted lines or max height carry extra attributes in their saved markup, so the editor flags them with “Block contains unexpected or invalid content.” Attempt recovery turns each one back into a plain Code block with the code intact, dropping only the settings the plugin reads.
Reactivate the plugin and the warnings disappear on their own. Compare that with a custom block you have to convert or rebuild by hand.
Two ways to highlight
The default Client-side (Prism.js) mode runs Prism.js in the visitor’s browser. Server-side (highlight.php) pre-renders the colors with highlight.php, so no JavaScript runs to color the code.
Either way, assets load only when a post on the page contains a Code block. Every other page loads nothing extra.
In server-side mode, one highlighter is shared across all the blocks on a page. Highlighting time climbs sharply with block size, so blocks over 128 KB are shown unhighlighted rather than stalling the page.
Both modes use the same 21 themes, with One Dark as the default, and produce the same output. The one gap: highlight.php has no GraphQL grammar, so GraphQL blocks stay plain in server-side mode. Client-side vs Server-Side Highlighting compares the two.
What you control per block
The Syntax Highlighting panel in the block sidebar sets the language, from 40 plus Plain Text, and the options that vary between blocks:
- File name or title, shown as a tab above the code by default
- Show line numbers, with a custom start line
- Word wrap
- Highlight lines, as lines or ranges such as
1,3-5 - Max height (px), which adds an Expand button
- Download button, to follow the global setting or override it
Copy and Download buttons sit in the toolbar and are on by default. Save as default stores the current block’s language, line numbers, word wrap and max height as the starting values for blocks that don’t set their own. Everything else lives under Settings → Code Block Highlighting.
Per-Block Controls and the settings reference cover each option in detail.
For developers
Every hook and function is documented on webberzone.dev. The filters below cover the common cases:
wzcbh_languages: add or remove languages in the picker. In client-side mode, the matching Prism grammar must also be on the page.wzcbh_color_scheme_css_url: use your own theme stylesheet.wzcbh_force_load_assets: load assets on every page, regardless of block detection.wzcbh_server_highlight_max_bytes: change the 128 KB server-side limit, or set it to0to turn server-side highlighting off.wzcbh_download_extensions: change the file extensions used for downloads.wzcbh_file_tab_html: replace the file name tab markup.
Install
The plugin is free on WordPress.org and needs WordPress 6.6 and PHP 7.4 or later. Search for it under Plugins → Add New Plugin.
For a step-by-step setup, see How to Add Syntax Highlighting to WordPress Code Blocks.
