A couple of weeks ago, I shared Remove Empty Shortcodes 1.1.0, which improved the plugin to do the one thing it exists for again: strip out the inactive shortcodes a deactivated plugin or page builder leaves behind. It worked. It just didn’t work everywhere.

1.2.0 is where “everywhere” finally means everywhere.

The Fix I Thought I’d Finished

In 1.1.0, I brought back removal of unregistered shortcodes. Case in point: Drop a post full of and from a retired builder, open it, and the junk was gone while your actual copy stayed put.

Except the clean up was only parsing singular views such as a single post or a single page. The gate was WordPress’s own is_singular(), and it seemed reasonable at the time.

But think about other places visitors can meet your content:

  • the blog home,
  • category and tag archives,
  • search results,
  • and the excerpts scattered across all of them.

None of those are singular views.

So the plugin was doing its job on the one page you’d click through to, and leaving the dead shortcodes sitting right there in every listing that led to it. Same plugin, same content, quietly not doing its job in the proverbial busiest rooms in the house.

The report that made it obvious was almost comically simple: the cleanup was working great on the full post, but the shortcodes were still showing up in the excerpts. Once I chased that down, the excerpt wasn’t really the problem. The is_singular() gate was.

What’s New in 1.2.0

It Cleans Everywhere Your Content Shows

The front-end cleanup no longer asks “is this a single post?” It asks “is this a post or page?” That one change means inactive shortcodes get stripped on single posts and pages and on the blog home, archives, and search results, wherever that content is rendered. If a reader can see it, the plugin cleans it.

All the care from 1.1.0 comes along for the ride: registered shortcodes that still do something are left alone, false positives like [at] in “email me [at] example [dot] com” are left alone, and by default the wrapper tags are stripped while the copy inside them survives.

Excerpts, Too

Excerpts get their own dedicated pass now, so the dead shortcodes are gone whether the excerpt is one you wrote by hand or one WordPress generated automatically from the post. This is the piece that started the whole 1.2.0 conversation, and it’s the piece most readers see first.

Bring Your Own Post Types

Out of the box, front-end cleanup covers standard posts and pages. If your content lives in a custom post type, such as content imported into a CPT whose plugin is long gone, there’s now a resc_supported_post_types filter to opt those post types in:

add_filter( 'resc_supported_post_types', function ( $types ) {
    $types[] = 'my_custom_type';
    return $types;
} );

The admin scanner already looks across every post type in your database; this lets the automatic front-end removal reach them too.

It Cleans Up After Itself

If you delete the plugin, it now removes what it created: its options, its cached scan results, and the little “dismiss the donate notice” flag. No orphaned rows left rattling around in your database. It’s a small thing, but it’s the polite thing.

Still Nothing Touches Your Database

The founding promise hasn’t moved: remove shortcodes from what’s displayed, never from what’s stored. Broadening the cleanup to archives, search, and excerpts didn’t change that one bit. Every one of these passes runs on content as it heads to the screen. Your post_content stays byte-for-byte intact, and reinstalling the builder brings every shortcode back to life as if nothing happened, because in the database, nothing did.

Under the Hood

A few things for the developers in the room:

  • A real coding-standards gate. In the 1.1.0 write-up I mentioned catching that the code had quietly drifted into PHP 8.0-only syntax while the header still promised 7.4. 1.2.0 makes sure that can’t happen silently again: WordPress Coding Standards plus PHPCompatibility now run in CI with a testVersion floor of 7.4, so an 8.0-ism fails the build instead of shipping.
  • The scanner reads in batches. It used to load every matching post into memory at once, which is fine until someone points it at a very large site. It now pages through the content a batch at a time, and the batch size is filterable via resc_scan_batch_size.
  • One detection routine, shared. The front end and the scanner now agree on what counts as a shortcode by using the same code path, so what the scanner flags is exactly what the front end removes.

Get It

Remove Empty Shortcodes 1.2.0 is live on WordPress.org. Install it, activate it, and the front-end cleanup just works, in every listing and every excerpt, with no configuration required. If you’d rather review what’s lurking in your content first, the scanner is still waiting under Tools → Empty Shortcodes.