I’m going to go against Betteridge’s Law of Headlines (sorry, Ian) because, I believe, the answer here is “yes”.

10 years ago, I was part of a conversation in Trac about WordPress’ housekeeping of transients. It was closed off with a half-hearted attempt to resolve the issue with the reasoning of…

This leaves much to be desired, but we don’t want a core update to be blamed for breaking a site that incorrectly assumes transients aren’t transient.

Basically, because some plugins may store data as transients, when they shouldn’t be, they were afraid to housekeep it fully.

But, let’s remind a little to understand what the issue is.

The Codex describes a transient thus…

The Transients API is very similar to the Options API but with the added feature of an expiration time, which simplifies the process… to temporarily store cached information.

WordPress Codex

The issue is that, although you can specify an expiry, the transient (which consists of 2 separate records in the options table) isn’t actually deleted until you attempt to access it after the expiry. If you don’t try and read it, it remains. So, a plugin that uses transients for caches can quickly built up a massive back-log of expired but still present records. Don’t believe me? A user of one of my plugins reported a 3.8GB options table as a result of exactly this.

So, that’s the background – now back to that discussion from 10 years ago. Although closed, discussions were had and some changes were made, mainly to housekeep transients when a database upgrade occurs (which sometimes happens during a major WordPress update). I didn’t accept the reasoning given for not implementing this, so wrote my own plugin – Transient Cleaner, which has remained a popular solution. Once a day it automatically jumps in and clears any expired transients.

However, it seems that in the intervening years, the issue has been re-discussed because in WordPress 4.9 (back in 2017), added in full housekeeping. It does – yes, you guessed it – exactly what my plugin does. Indeed, the SQL, apart from how it handles dates, is pretty much the same. Like my plugin it runs daily and the same housekeeping code is used during the database upgrade too.

What does my plugin now do that this doesn’t? Not much, other than allow you to run it manually.

Users report it still helps them when they various issues, but whether this is a simple placebo, a transient that’s expired since the last run, or their cron simply not running (which my automated housekeeping wouldn’t resolve anyway), I don’t know.

Which leaves me with one question – what’s the point of my plugin anymore? Whilst it’s tempting to now close it, I do wonder if I could consider modifying it to remain as-is but just to use the core function now, instead of my own. Reduce down but, most importantly, keep the manual run option. One thing I don’t want to do is keep the plugin for those users on versions of WordPress prior to 4.9.

I’ll see.

If you’re a user of my plugin, please let me know what you think.

Plugin Update #2…

What’s the point in having a mind if you never change it?

After further consideration, I’ve decided not to stop development of the existing plugin. Version 1.6, just released, will be the last version of the current iteration, designed for WordPress 5.8 and below. Version 2 will support ALL versions of WordPress, making use of the built-in housekeeping functionality for version of WordPress after 5.8. It will be a ground-up rewrite, allowing all versions to have more control over when and how the housekeeping occurs.

Stay tuned!