Last week, I discussed everything that went my decision on retiring site memberships. For those who were members (or even read the initial idea), you may recall that I was using Restrict Content Pro to power the site.

When retiring the memberships, I wanted to make sure I was able to maintain the integrity of all of the posts that I’d published simply without the shortcode that comes with RCP.

What started off as a simple plugin to remove the RCP shortcode turned into a plugin to remove all empty shortcodes. I’m opting to open the plugin’s repository so anyone can access it (or contribute issues, code, or create their own fork from it).

At the time of this writing, the plugin is at 0.4.0 so there’s not much to expect. But I enjoy reading the what and why other developers do in their projects, so I’m going to do so with Remove Empty Shortcodes.

Remove Empty Shortcodes

As the README (and plugin description) states:

Removes all empty shortcodes from WordPress standard post types.

Remove Empty Shortcodes

But there’s a bit more to it: This plugin removes the shortcode from what both users and search engines see. 

The Approach

There were deliberate decisions that went into this specific approach (and I give credit to a couple of friends for talking it through with me). Initially, the goal was to write a function that ran a database query, looked for the plugin’s shortcode in the post_content and then simply removed the opening and closing tags from the content.

This presents a problem, though: What if I – or anyone else using the plugin – opted to reactivate the plugin and honor the shortcodes? This would require the author to keep a log of all of the previously protected posts so that they could return and reinstate the paywall.

Conversely, both users and search engines should be able to read the content without having any additional work imposed on the author.

And that’s what the plugin does.

Development

Initially, this was going to be a simple plugin. It was going to be a set of functions that ran a query against the database with results that couldn’t be reversed.

But if you’ve peeked at the source code already, then you know that’s not how this was built.

Instead, I opted to use the following tools:

  • GrumPHP for code quality tools.
  • Composer for working with the various packages that are used with GrumPHP.

And then the plugin, at a high-level, is structured like this:

  • the plugin bootstrap,
  • a registry in which all of the references for various objects are maintained,
  • subscribers for creating a link between certain WordPress hooks and domain objects,
  • a shortcode utility for managing activate and inactive shortcodes,
  • a class for processing public-facing standard post types,
  • a core pluign file that iterates through the registry and sets up the subscribers.

All of the code is documented and follows PSR standards along with some object-oriented principles such as abstract classes. There isn’t much yet but in the future, I’m looking to expand the set of features.

What’s Next?

Though I’ve included a basic TODO file in which I’m tracking future features, I’m looking to build out the repository with this information in the form of issues, documentation in the wiki, and so on.

With that said, you can download and install the plugin (but use it as your own risk, of course). No content is altered at the database level so you shouldn’t lose anything and the master branch of the plugin even includes the vendor directory so the necessary dependencies for an installation is included.

This includes the GrumPHP tooling and the related dependencies for those of you developer types who are interested in trying it out (however, I may move this out of master in a future version).

There are no plans to include this in the WordPress Plugin Repository but everything regarding the plugin will be located on the site and will filed under this tag.