Practical WordPress Development

Introducing Markdown Code For WordPress

For those who have been reading this blog for sometime, you know that I’m a fan of using lines of code in my posts.

I’m not referring to the larger code block (I use SyntaxHighlighter Evolved for that), but for code that exists in a single line much like this. The thing is, when I’m drafting my posts, I often place those strings in backticks – `like this` – and then go through and replace them code tags prior to publishing the post.

Tedious, right?

And I love Markdown as much as the developer, but I’m not ready to fully abandon the WordPress editor for it. Instead, I’d rather have just a few tags supported that I frequently use and be able to have them replaced automatically.

So I wrote a really simple plugin for doing just that: Markdown Code For WordPress.

Markdown Code For WordPress

Markdown Code For WordPress

The Markdown Code For WordPress GItHub Page.

Simply put, this plugin will replace all backticks in your post, page, or other custom post type content and replace it with the proper code tags so that you don’t have to manually do so.

Sure, it’s really simple, but it scratches a nasty itch of mine and will ultimately save me a lot of time.

But as with most projects, I always welcome notes, pull requests, and discussion around it so I placed it on GitHub for exactly that reason.

What’s Next?

Honestly, I have no roadmap for this plugin. As I mentioned, it fulfills a need that I’ve for sometime while writing for this blog, so I wrote it for myself and am sharing it just in case anyone else has the same need.

Additionally, I’m not really into leaving the WordPress editor, but I’m not opposed to introducing support for other tags depending on if others use this particular plugin.

A Note About Parsers

For those who are familiar with writing parsers, you know that languages – like markdown – normally include a parser that’s responsible for replacing tokens with their appropriate tags in the grammar.

This plugin does not do that – it’s not mature enough for that. Truth be told, it’d be much easier to wrap the Markdown parser in a WordPress plugin and then call it a day.

Instead, Markdown Code For WordPress uses a simple regular expression for replacing the backticks with code tags.

I mention this so that if this particular project ends up gaining any sort of traction with including support for other tags, then I’d want to make sure that we’re not reinventing the original Markdown parser, and that we’re not simply adding a collection of regular expressions (as creating a parser would be the proper way to go).

Download It

You can follow development of Markdown Code For WordPress (though I’m not sure how active it will be) on its corresponding GitHub page. If you want to download the latest version, then you can do so using this link.

As with the rest of the projects, I’m always interested in feedback so feel free to leave some in the comments or on GitHub.


  1. Brad Dalton

    Any reason you don’t use Gists?

    • Tom McFarlin

      Mainly because I’d end up with a huge collection of them over time. In some cases, that’s awesome, but half the time I’m sharing code that demonstrates what not to do, so I’d hate for that to be floating around the gistophere :).

      Plus, when comments are left on gists, I don’t get emails which means I’d have to bookmark, and periodically check gists on my own whereas I can embed the code in my posts and just manage the comments as they roll in.

      Basically, it’s an issue of ease for me :).

      • Jesse

        Been a long time since this comment but just wanted to chime in here and say this is why I don’t use Gist, either.

        • Tom McFarlin

          I’ve recently started using Gists in my more recent posts, but I keep them secret and I make sure that they are going to be things that I want to refer to in the future so that I’m building a library of snippets that will be useful beyond just this blog.

          I still use basic code blocks when I want to demonstrate something simple, but more elaborate stuff that I’m bound to use in the future are now kept in gists.

    • Shea Bunge

      This is mainly used for inline code, not code blocks.

  2. chris mccoy

    i see you are just performing a regex on the_content, any other way to do this? shortcode maybe for code?

    • Tom McFarlin

      Are you asking why I wouldn’t do something like <code>This is my code snippet</code>?

  3. Pippin

    Nice :D

  4. Konstantin Kovshenin

    Cool beans! Two things. First: why not carry out the search and replace once before the post is saved and not every time it is displayed? Second: not a big deal, but the . meta character also matches `, so in your case, using /`([^`]*?)`/ would probably be easier to read/understand, and hopefully more efficient, since you can simply replace it with backtracking without having to run preg_replace three times:

    $content = preg_replace( ‘/`([^`]*?)`/’, ‘<code>\1</code>’, $content );

    That’s off the top of my head, might not even work, but you get the idea :)


    • Tom McFarlin

      I didn’t want to do prior to saving the post just in case people use it, opt to disable the plugin, and then want to go with some other markdown editor or some other plugin. This keeps the original tokens in take so they can do a search and replace for it.

      I’ve had a couple of plugins where I’ve tried permanently alter the content prior to writing to the database table and people haven’t been too happy when they’ve disabled the plugin.

      Can’t please ’em all, I guess :). Plus, this is so minuscule that the performance is negligible.

      Also, your suggestion for the regex is actually what the initial implementation was (funnily enough); however, I got to experimenting with other tags and with using the callback last night and I still may go back and add support for a few small things.

      Ultimately, it was a matter of getting it out, working, and installed. But I still dig this idea so I’m going to add this as a potential issue in GitHub.

      • Shea Bunge

        Regardless of what might be best for the majority, it would be nice to see an alternative version that translated the backticks into &th;code> on post save, not on render.

        • Tom McFarlin

          I’ll be adding this as an issue in the repository to see about changing on an uninstall hook.

          Not a bad idea, Shea.

    • Konstantin Kovshenin

      You can also drop the lazy quantifier from the group since it won’t match ` anyway.

Leave a Reply

© 2020 Tom McFarlin

Theme by Anders NorenUp ↑