Software Engineering in WordPress, PHP, and Backend Development

Category: Projects (Page 1 of 32)

Posts introducing, updating, and covering various projects to which I’ve contributed or that I maintain.

Remove Empty Shortcodes 0.6.0

In 2019, I wrote a WordPress plugin that’s primary feature was to prevent unused shortcodes from rendering in the content whenever a page was loaded.

It worked well enough for a little while. Then time passed.

During that time (and for one reason or another):

  • I removed all of my plugins from the WordPress plugin repository,
  • I focused on a number of different things both professionally and personally,
  • And though I let this plugin remain on GitHub (as opposed to archiving it), I stopped maintaining it.

Just recently, I came across the problem of rendering orphaned shortcodes again and I noticed someone had left an issue in GitHub. So I decided to rewrite the plugin, tag a release on GitHub, and release it into the WordPress plugin repository.


Remove Empty Shortcodes, Again

The original repository page for Remove Empty Shortcodes.

When I first wrote this plugin, I had stopped using Restrict Content Pro but the shortcodes were still littered throughout various posts in my archive. And this exposed a larger problem with shortcodes as a whole:

If a user installs a plugin that uses shortcodes and then deactivates the plugin, the shortcode will still render in the content of the post.

Obviously, this muddies the content for readers by leaving artifacts of code that’s no longer running. So rather than query the database for shortcodes that were orphaned in my content or just remove a single plugin’s shortcodes, it seemed easier to do something else: Automatically remove empty or inactive shortcodes from my WordPress content while preserving the original database entries.

And that’s what this plugin does. Specifically, it intercepts the content before it’s rendered, removes the shortcodes, then passes the rest of the data back to the main process to render the content.

The updated repository page for Remove Empty Shortcodes.

This ensures that if you ever reactivate the plugin, the shortcode still exists and will work as intended.

As of this post – and this version – the plugin only works on post and page post types.

You can read all about the details for the plugin (including the FAQ) on both GitHub or the Plugin Repository but here’s the gist of information relevant to this post:

How It Works

The plugin checks your content for shortcodes when pages are displayed. If it finds shortcodes that:

  • Don’t produce any output
  • Aren’t registered with WordPress
  • Are empty or inactive

Then it removes the shortcodes from the content before rendering it in the browser.

Use Cases

  • Clean up content after removing plugins that used shortcodes
  • Remove inactive shortcodes without editing posts manually
  • Maintain clean content for readers and search engines
  • Preserve original content in case you reinstall removed plugins

Conclusion

It’s been a long time since I’ve released a plugin in the WordPress Plugin Repository (regardless of how large or small) let alone bothered writing about one on this site.

But since this is one of those things that I’m using on a site with over a decade and a half of content, it may be useful for someone else, as well.

And yes, there additional things that thing plugin could do and maybe it will but that will largely depend on adoption or my own needs or both.

Code Standard Selector for Visual Studio Code

A lot of the PHP that I currently write uses one of two standards: PSR12 or WordPress (though there are some times where I’ll pull up another project with a different standard).

For years, my standard approach to changing code standards in the IDE has been to do the following:

  1. Install the standard that’s required (if I don’t already have it),
  2. Modify settings.json in Visual Studio Code so that it uses the same standard used in the rest of the project.

It’s a little cumbersome but it worked well enough. Overtime, I end up with a lot of settings commented out that I enable based on the project.

But this was getting tedious.

Instead, I preferred to quickly select and change coding standards within the IDE via the command palette or, really, a shortcut. So I wrote a Visual Studio Code Extension to do exactly that.


Code Standard Selector

PHP Code Standard Selector is a Visual Studio Code extension that makes it easy to switch your PHP coding standard without having to edit any settings in your IDE.

Using this extension, you can view and select the coding standards in three ways:

  • The command palette, type > Select Code Standard
  • A shortcut, CMD+ALT+S or whatever the equivalent may be on Windows and Linux,
  • The status bar, which shows the currently selected standard and gives you the ability to click on said standard to change the standard

All three of these options render the same menu: A list of all of the standards installed on your system. Once selected, the extension will then automatically set that standard as the active standard and apply it to your project.

Prerequisites

Note, however, there are a few prerequisites to use this extension. Code Standard Selector assumes – and requires – you have the following set up on your system:

PHP CodeSniffer is usually installed via Composer and PHP Sniffer & Beautifier (abbreviated as PHPSAB in Visual Studio Code) is installed via the Extensions Marketplace.

And if PHP CodeSniffer is installed at the project level, it’s easy enough to update the paths to phpcs and phpcbf in your User Settings or Workspace Settings.

Installing The Extension

You can find it in the Visual Studio Code Marketplace in your browser or searching for “Select Code Standard” in the Extensions Marketplace in the IDE itself.

Or, if you prefer, you can download the lastest vsix release from the GitHub repository (where you can also grab the code, open issues, feature requests, and all of the usual options provided by a repository).

How It Works

Select Code Standard will check to make sure that the PHP Sniffer & Beautifier is installed and, if not, prompt you to install it before allowing you to actually use the extension.

Obviously, installed that particular extension implies you have at least one set of coding standards installed on your system.

Once installed, Select Code Standard will then generate a list of all standards installed on your system (by using phpcs -i) and use that to render the list of available standards.

When you select a standard, it will then use the value of the standard to tell PHP Sniffer & Beautifier what to use and it will update the extension and status bar with the standard currently in use.

Example Configuration

If you’ve not used PHP Sniffer & Beautifier before and you’re looking to get up and running quickly, here’s an example of my configuration in settings.json:

"phpsab.executablePathCS": "/Users/tommcfarlin/.composer/vendor/bin/phpcs",
"phpsab.executablePathCBF": "/Users/tommcfarlin/.composer/vendor/bin/phpcbf",
"phpsab.fixerEnable": true,
"phpsab.snifferShowSources": true,
"phpsab.standard": "PSR12",
"php.validate.run": "onSave",
"": {
    "editor.formatOnSave": true
},

Notice the line that contains phpsab.standard. This is the one that Select Code Standard will modify when you select your own standard from the extension’s interface.

Issues, Requests, Future Versions, etc.

I built this extension for me because I wanted to have an easy way to quickly change standards (and because I’d never built an extension for Visual Studio Code before).

If you’re a developer using PHP and have a similar set up – or are looking for a way to update your set up to something that works well with the aforementioned configuration – maybe this extension will help.

Further, I’ve set up templates in the GitHub repository for opening issues, bug reports, feature requests, and so on. You can read more about the plugin in the README, as well.

Finally, although the plugin can be automatically updated from within the Extensions Marketplace, each version will be released on GitHub prior to deploying in the marketplace. So if you typically follow – or star – repositories to track development, that’s an option.

With that said, I’m already using the Select Code Standard and it’s serving its purpose exactly as I need. If it works for you, great. And if you have issues, requests, or anything else, please open an issue.

Fetch Album Artwork for Apple Music Playlists

TL;DR: I often create playlists for entire albums within my Apple Music library. This means that if an artist releases an album, I’ll still add it to my library, but I like to have a playlist of just that album. Unfortunately, Apple Music doesn’t use the album’s artwork as the image for the playlist.

So I wrote a Python script to fetch album artwork for Apple Music playlists when given an artist and an album. This makes it a little bit easier to make sure album playlists have better looking artwork.


Fetch Album Artwork for Apple Music

Whenever we create playlists within the current version of Apple Music, it gives us the ability to create playlist art that seems to be inspired by the Microsoft WordArt of decades past.

It’s certainly a choice. And for whatever reason, Apple Music doesn’t default to the album artwork for the album in the playlist if it’s just a single album.

Apple Music does allow us to add custom artwork, though. So if I want to add the album artwork for a given album in a playlist, then I can search the web for a high-resolution image and drop it into the editor for the playlist.

Perhaps a better option, though, is to grab the image artwork from the iTunes API. So I wrote a Python script that makes it trivially easy.

After it’s installed, all you need to do is issue the following in your terminal:

$ python fetch-album-art.py --artist="Pink Floyd" --album="The Dark Side of the Moon"

This will grab a high-resolution image of The Dark Side of the Moon and drop it into the script’s directory after which you can add it to Apple Music.

Future State

Assuming Apple doesn’t actually address this in a future version of Apple Music (which, if history is any indication, happens with each official macOS update), then this is something that’ll prove useful [at least for me] for the next little while.

That said, I’d still like to find ways to enhance the functionality so:

  • album artwork is added to its own directory,
  • considering combing through an Apple Music playlist library to determine what albums don’t have artwork (this is subject to the limitation of the API, obviously),
  • provide better visual feedback when the script is searching and downloading the album artwork,
  • and small tweaks like that.

Given that it’s a hobby project, though, it’s one of those that’s subject to the whims of when I want to work on it.

For now, though, this is still one step better than having to find an image via a web browser, download it, then drag it into Apple Music.

Dracula Theme for Preformatted WordPress Blocks

When working on the articles for the Backend Engineer Learns to Build Block Editor Blocks series, I wasn’t happy with how the code samples were looking within the articles.

Previously, I’ve written – here and here – about my being a fan of the work done by Zeno Rocha in the Dracula Theme. Ideally, I wanted to be able to have the color scheme of the code in my articles match the theme. Something like a Dracula Theme for WordPress Blocks.

That’s when I found highlight.js and a Dracula theme for it. So I wrote a small plugin for WordPress that works with the existing Preformatted block and changes the color scheme to match that of Dracula.

I call it WP Dracula Highlight.js or, more simply, Dracula Highlight.

Continue reading

WP Plugin Scaffold: Easily Start a Composer-based WordPress Plugin

TL;DR: The WP Plugin Scaffold repository contains a a very basic set of files that are needed to spin up a Composer-based WordPress Plugin.


Over the years, I’ve written or contributed to a number of different projects that have been aimed at making WordPress plugin development easier. At this point, there are a variety of ways people are creating WordPress plugins such that there isn’t really a way to create a boilerplate to capture all of them.

So I’m not aiming to do that.

But over the last few months (or maybe a year?), I’ve been working with the same structure for creating plugins. It normally grows into something larger based on if I’m taking an object-oriented approach or a procedural approach. It also changes based on how large the plugin is, what its purpose is, who is going to use it, or how it’s going to be used.

To that end, I’ve ended up with a very basic set of files that every project incorporates regardless of the size.

As such, I thought I’d share it.

Continue reading
« Older posts

© 2025 Tom McFarlin

Theme by Anders NorenUp ↑