WordPress is a long running machine, and in most of my 11 year experience using it, have found it rather forgiving with old code and themes.

With the 4.7 WordPress update, I have been seeing a problem with the Feed WordPress plugin, and despite a fix I found that cleared the error, tonight I found the fix broke other related plugins.

Sadly the developer of this plugin much of my syndicated blogging work has revolved around is a bit absent on issues with his code.

That has to wait for another day.

I ran into another problem with a plugin, it’s one that presents code I put into my blog post into a more readable format. Syntax Highlighter Plus has worked without problem on my site for several years, but tonight, it’s borking. The problem has to do with some new way WordPress has coded global filters. I could not untangle the code enough to find a remedy.

The first recourse is disabling the plugin. The problem this presents is that the way it worked is I wrapped all my code with a pair of shortcodes like:

[sourcecode lang="javascript"]
    
[/sourcecode]

Nearly all my stuff has an attribute for lang= of php or javascript. This is the hitch of using shortcodes; when I disable the plugin, my posts are going to be littered with bits of [sourcecode lang="php"] ... mumbo jumbo .... [/sourcecode].

My strategy was to find another syntax formatting plugin (there are quite a few), and Crayon looked like a good pick. It’s recent, has a fair number of installs and reviews.

I installed the plugin and tested it. Yup, it formats code. The thing is that uses a different (and better IMHO) construct than shortcodes; it wraps code in <pre>...</pre> tags with a class attribute that defines the display language, e.g.<pre class="lang:php">... </pre>

I started thinking about a function I could add to hook into the_content to do a search and replace on the shortcodes. I even got as far as getting a grep search to work.

The I thought of an easier plan. I just need to do a one time search and replace on all posts that used these tags. And I remembered you can do this on the database in phpMyAdmin. I fired up mine via my lovely Reclaim Hosting cpanel.

I fund the wp_posts table in my blog, that’s where all the content for blog posts live and breathe. Actually I first duplicated the table in case I messed up.

I clicked the SQL tab so I could run direct queries (not for the feint of heart), and ran this one to replace all the closing [/sourcecode] shortcodes with </pre>ones:

Bam! I got like an update to 38 posts. I checked one. Sure enough the search and replace worked. I then ran a few more like:

or in phpMyAdmin:

Note: I spent way too much time getting <pre> tags to work within <pre> tags!

It does feel powerful.

I tested the new plugin and it worked great, like for this post from just 2 a few months ago.

The Crayon plugin has all kinds of crazy options, one is you can set a default style theme for how code is presented.

I thought I was done. But to make sure, I searched in the dashboard my posts for [sourcecode and found another 20+ posts. That’s because I also had code with the lang= setting for html, xml, css not to mention PHP, Javascript, and JavaScript (remember kids that search is case sensitive), not to mention a handful of posts where I had used language= rather than lang=.

It just meant another spate of mySQL replace queries. Which are damn useful to know how to do if you need to back mod a bunch of old posts (yes a more brute force way would be to do an entire export of my database, an run search and replaces locally on the file, and re-populate the database; but my old big blog is a big creaky ship, about 75 Mb of database) (and running mySQL queries feels more geeky cool).

There’s a lot more to the Crayon plugin to figure out, it hooks right into the dashboard post editor, so it will make adding code chunks a bit less manual tag typing like I did before.

And now my blog is again (until the next mishap) is a fine tuned machine

UPDATE Dec 12 I have been fiddling with this way too much. The problem is the Crayon plugin affects all instances of the <pre>...</pre> tags, so I set it’s default to use the Plain White theme and to never show the toolbar for those boxes where I did not want code formatting.

THEN I ran my mySQL updates to modify the ones where code was used, to replace with tags that include a darker Crayon theme and to show the toolbar.

I better stop now….


Top / Featured Image: flickr photo by waferboard https://flickr.com/photos/waferboard/30182796173 shared under a Creative Commons (BY) license

If this kind of stuff has value, please support me by tossing a one time PayPal kibble or monthly on Patreon
Become a patron at Patreon!
Profile Picture for CogDog The Blog
An early 90s builder of web stuff and blogging Alan Levine barks at CogDogBlog.com on web storytelling (#ds106 #4life), photography, bending WordPress, and serendipity in the infinite internet river. He thinks it's weird to write about himself in the third person. And he is 100% into the Fediverse (or tells himself so) Tooting as @cogdog@cosocial.ca

Comments

  1. bitrot like change is a constant 🙂 good luck on the bitrot in the Feed Press WordPress plugin; i feel your pain and like you I have felt the pain of plugin-in/add-on breakage on many pieces of software over the 3 decades I’ve been in the software industry.

    This is why I try to avoid using plugins and add-ons in any software (emacs, firefox thunderbird, heck even jekyll where I am using the default theme); eventually they all stop working without some sort of change usually non-trivial

Leave a Reply to Roland Tanglao Cancel reply

Your email address will not be published. Required fields are marked *