Four Plugins, One Release Day

On 20 September we published four WordPress plugins on the same day.

That was not a coincidence of scheduling. A platform release was changing the editor underneath all four, and a plugin that has not been checked against a new WordPress version is a plugin that might break for every user who updates — which most will, automatically, without asking anyone.

The interesting part is not the release. It is what preparing it found.

Why they went out together

WordPress 7.1 changed how the block editor loads. Among other things, the editor is now always framed, which affects how a plugin attaches its own interface to it — a plugin that assumed the old arrangement can end up with a sidebar that does not appear, or appears and does nothing.

Four of ours touch the editor or the admin in ways that assumption reached:

• supan-seo — a Gutenberg scoring fix, the editor script dependency the always-framed editor requires, and a change to how it writes the site’s llms.txt file.
• supan-reputation — compatibility with WooCommerce’s new order storage, review requests moved onto a scheduled queue, and a decryption fix.
• supan-content — clearer error messaging in the editor sidebar.
• supan-backup — brought onto the same footing.

When a platform change reaches several of your products, releasing them separately over three weeks means three weeks where some of your customers have a matched set and some do not. One day is less work and fewer combinations.

The defect our own repository could not see

Here is the finding, and it generalises to anyone distributing software through a channel.

Our plugins are published to the WordPress directory through its own version-control system, separate from the repository where we develop them. Releases get pushed to the directory, and our own repository catches up afterwards.

Which means our repository is not the record of what shipped.

Checking the published versions against ours, before the release, found they had drifted:

One plugin had ten unreleased items sitting in its changelog under a version heading that had already been published. So the version number in our tree and the same version number on the directory described different code — under a label that, once published, cannot be reissued. Anyone already on that version would never have received those fixes, because to their site it was already installed.

Another was worse in a different way. Two items the directory had actually published for a version were missing from our repository entirely, along with that version’s upgrade notice. Its changelog then described the new release as having no functional changes — for a release that adds compatibility with a new order storage engine, moves email onto a scheduled queue, and fixes a decryption bug.

Three functional changes, described as none.

★ Insight ───────────────────────────────────── The general shape: whenever the thing customers receive is published from somewhere other than where you develop, the two will drift, and your own repository will confidently tell you the wrong story. It is not a version-control problem, it is a direction-of-truth problem. The fix is to check the published artefact before every release rather than the source — which sounds obvious and is almost never done, because the source is the thing on your screen. ─────────────────────────────────────────────────

Every claim checked against the code

So the changelogs were rewritten, and each statement was verified against the code rather than taken from the commit messages that produced it.

That distinction is worth explaining because it sounds like pedantry. A commit message describes what someone intended when they wrote the change. A changelog describes what the software now does. Those diverge when work is reverted, split across commits, or renamed — and nobody notices, because the commit message was accurate when it was written.

For the reputation plugin that meant confirming each item in the code: the compatibility declaration, the scheduled-event call behind the queue, the guard that prevents an order being queued twice, the note written onto the order on both the successful and failed paths, and the corrected offset arithmetic behind the decryption fix. Also confirming, by search, that no licence key exists anywhere in the codebase — a claim worth verifying rather than assuming.

Why a small business should care about any of this

Two practical takeaways for anyone running a WordPress site, which is most Australian small businesses.

A plugin that has not been updated since before a major WordPress release is a risk, not just an inconvenience. Automatic updates mean your site can move to a new WordPress version on a schedule the plugin author did not plan for. The date of a plugin’s last update, visible on its directory page, is the single most useful thing on it.

A changelog saying “no functional changes” is not reassurance. It may be accurate. It may be a release note nobody rewrote. If a plugin handling your orders, your customer data or your backups publishes an update, the upgrade notice is worth ten seconds of reading — and if it says nothing at all about what changed, that is information too.

What we changed in how we work

One process change, and it is small: before any release, compare the published version against ours and reconcile the changelog first. Not after. The reconciliation is what tells you which version number the new work can legitimately go under, and getting that wrong is the one mistake in this whole exercise that cannot be undone.

---

Ganda Tech Services builds and maintains WordPress plugins and websites for Australian businesses. Site builds and maintenance come through Cosmos Web Tech, hosting and infrastructure through Cloud Geeks.