The empirical companion piece on what we actually installed, measured, and switched to when evaluating syntax highlighting.
Table of Contents
Why we compared these two specific plugins
This is a direct, two-plugin comparison rather than a massive roundup of every available option. We evaluated the incumbent plugin we were already using against our chosen replacement to see exactly what would change in our automated publishing pipeline.
The two plugins we tested were Code Block Pro (version 1.28.0) and Syntax-highlighting Code Block (version 1.5.2) by Weston Ruter. The former relies on the Shiki engine and applies formatting on the client side at save time. The latter uses highlight.js on the server side and simply extends the native WordPress core/code block.
Server-side highlighting adds nothing to stored content, making it a pure render-time enhancement.
What we measured during the transition
We ran a live before-and-after test on an already-published post. The goal was to leave the post_content byte-for-byte unchanged while toggling the new plugin. When we activated the Syntax-highlighting Code Block, the page added 49 specific classes and 60 highlight spans to the front end. Most importantly, the four wp:code blocks in the database remained completely unchanged.
This unchanged post_content is exactly what we wanted. Since the markup is only altered when the page is generated, a projector can emit plain code blocks and rely on the server to handle the presentation.
We declared the fence language directly rather than relying on auto-detection to prevent drift.
Lab verification and engineering decisions
We followed up the live test with a disposable lab verification. The new plugin correctly attached copy buttons to the code blocks, applied line numbers to blocks with declared languages, and handled zebra striping via logical lines.
We made two specific engineering decisions based on this test. First, the projector was updated to explicitly declare the fence language (like PHP or HTML) instead of relying on the highlighter to guess. Second, we noted a secure-context restriction: the copy button intentionally does not render on plain HTTP environments, degrading gracefully to a manual copy prompt.
If you are curious about the broader theory behind where highlighting should happen, that decision requires understanding the trade-offs between build-time, server, and client execution.
The short version
We replaced a client-side code highlighter with a server-side alternative to keep our database clean. By testing Syntax-highlighting Code Block, we proved that we could get full styling and copy buttons on the front end without permanently altering the source text in the editor.
Frequently Asked Questions
Why did you switch away from Code Block Pro?
Code Block Pro saves its highlighted markup directly into the database. If we ever disabled the plugin, the formatting would break or leave behind unnecessary HTML, creating a hard dependency in the editor.
What are the benefits of server-side code highlighting?
Server-side highlighting keeps your raw content clean. The code remains plain text in your database, and the styling is only applied when the visitor requests the page, making future migrations much easier.
Did you test any other WordPress syntax highlighters?
No, this specific evaluation was a direct comparison between the plugin we were already using and the exact alternative we planned to adopt for our automated pipeline.
Why is it important to declare the code language?
Declaring the language ensures the syntax highlighting rules are applied accurately every single time. Auto-detection can sometimes guess incorrectly, leading to confusing formatting for your readers.
