tl;dr
If you switched from another syntax highlighting plugin to SyntaxHighlighter Evolved, and all your codes are scrambled, try running the following code as a single-file plugin.
function xiaodu_syntaxhighlighter_fix() {
return 2;
}
add_filter('syntaxhighlighter_pre_getcodeformat', 'xiaodu_syntaxhighlighter_fix');
The easiest way is to go to Plugins – Plugin Editor, and paste the code at the bottom of any enabled plugin, maybe Hello Dolly.
Long version
After almost three years I finally started working on this blog again.
One of the first things I noticed is that the syntax highlighting plugin I used, Crayon Syntax Highlighter, is dead. Well, to its credit, the server-rendered markups it generated were… fine when I started this blog, but nowadays they just look sickening to me, especially when compared to the neat client rendering solutions.
So I went to the store and downloaded the most popular choice, SyntaxHighlighter Evolved, which uses the JavaScript library SyntaxHighlighter to perform client-side highlighting. After installing it and converting all my old code tags to their markup format, I found the highlighting to be working, but all the C++ and HTML looked screwed up.
As you can see, all the “<“, “>” and “&” in the code are now showing up as their HTML entities – “<”, “&rt;” and “&”. That is not cool, so I looked into the problem.
Looking under the hood
First thing we need to know is how the code is stored in the post. When I click on the “Text” tab in the post editor (yep, the old one… I haven’t adapted to the new blocks yet,) I found that the characters are displaying correctly.
Then I looked further into MySQL, and the code is stored encoded, which is fine – it can be stored in the database however it fits, as long as the final output is correct… which it isn’t.
Pinpointing the plugin code
Now that I know that the plugin did an extra encoding, I looked for “htmlspecialchars” in the plugin’s GitHub repository, and found this piece of code:
// This function determines what version of SyntaxHighlighter was used when the post was written
// This is because the code was stored differently for different versions of SyntaxHighlighter
function get_code_format( $post ) {
if ( false !== $this->codeformat )
return $this->codeformat;
if ( empty($post) )
$post = new stdClass();
if ( null !== $version = apply_filters( 'syntaxhighlighter_pre_getcodeformat', null, $post ) )
return $version;
$version = ( empty($post->ID) || get_post_meta( $post->ID, '_syntaxhighlighter_encoded', true ) || get_post_meta( $post->ID, 'syntaxhighlighter_encoded', true ) ) ? 2 : 1;
return apply_filters( 'syntaxhighlighter_getcodeformat', $version, $post );
}
// Adds a post meta saying that HTML entities are encoded (for backwards compatibility)
function mark_as_encoded( $post_ID, $post ) {
if ( false == $this->encoded || 'revision' == $post->post_type )
return;
delete_post_meta( $post_ID, 'syntaxhighlighter_encoded' ); // Previously used
add_post_meta( $post_ID, '_syntaxhighlighter_encoded', true, true );
}
Apparently years ago they changed how codes are stored in the post. Now if you write and save a new post with their plugin installed, they will save the code already encoded, and insert a post meta “_syntaxhighlighter_encoded = True” to mark the post as the “new (encoded) format”.
But if you are like me who used other plugins when initially posting the code and later switched to Evolved, you are in bad luck, as they consider your post by default the “old format,” and will encode the code again in the final output.
Solution
The apparent solutions it to make the plugin think that all my posts are in the new format. I could add the same metadata to each of the posts, but luckily there is a easier way: Use the filter “syntaxhighlighter_pre_getcodeformat” (line 8 in the code above) they provided to override the result.
So I used the plugin code at the beginning to hook it. The hook function simply returns 2, which means all my posts, with or without the metadata, will be considered the already-encoded new format, so they will not be doubly encoded.
It’s been years, is that all you have to say?
OK, fair enough. So this blog may look the same, but the tech underneath it is constantly changing.
For example, all my appliances are now hosted on my own bare-metal (as opposed to cloud-vendored like GKE) globally-distributed Kubernetes cluster. Also, I have been hiding behind CloudFlare for years to avoid the haters, but now they are mostly gone (or grown up ?,) so I have been thinking of new ways to distribute my content.
All of these new stuff are exciting and worth sharing, and I will write about them soon™.