Shipping plugin updates safely

A plugin update is a code change you push onto someone else’s production site, usually while they are not watching. That framing shapes everything about how we release.

One version number, derived not duplicated

Every CHADA plugin has exactly one place its version is written: the Version: header in the main plugin file. The PHP constant the code uses is read from that header at runtime rather than typed out a second time.

This sounds pedantic until you have shipped the bug it prevents. A plugin whose header says 2.1.0 and whose constant says 2.0.9 will offer an update that installs and then offers itself again forever, because the updater and the plugin disagree about what is installed.

One command, and it reverts itself

Releases go out through a single script per plugin: bump the version, build a clean ZIP, publish it. There is no sequence of manual steps to get half-right at the end of a long day.

The build stages the plugin into a clean directory and excludes what has no business on a customer’s server — tests, tooling, node modules, and above all deploy credentials. If the upload fails, the version bump is rolled back automatically, so a retry does not inflate the number and produce a phantom release that was announced but never shipped.

The update path

Installed sites poll our update endpoint on a schedule. The server compares the version in the release manifest to what the site reports and answers with either “nothing new” or the details of a newer release plus a signed, time-limited download URL.

Two details matter here. The download URL is signed at the moment of the check, so the download endpoint cannot be used to fetch a version the site is not entitled to. And update checks are cached for up to twelve hours, so a site does not hammer the endpoint — with WordPress’s “Check Again” button bypassing that cache when someone genuinely wants the answer now.

Entitlement, stated plainly

Who gets which version follows one rule set, and we would rather write it down than have people discover it:

• Free plugins — everyone gets the latest version. No licence involved.
• Active licence — the latest version.
• Expired or suspended licence — frozen at the version that was current when the licence lapsed. You keep what you had; you do not get newer. Renew and the freeze lifts.
• No licence — no update.

That middle case is the one people ask about, so to be explicit: an expired licence does not remove an update you already installed, and it does not disable the plugin. It stops new ones arriving.

Tested-up-to is set by the build, not by hand

Each build stamps the WordPress version we tested against into the release manifest and the plugin’s readme. Keeping that current is what stops WordPress showing your customers an alarming “untested with your version of WordPress” warning on a plugin that is, in fact, fine.

Back up before you update

The honest position for any plugin vendor is that we test as carefully as we can and cannot test against your particular combination of theme, plugins and host. A good backup before an update is worth more than any promise we can make about ours.

That is a large part of why we built Chada Backup, and why its recovery points trigger on WordPress core, plugin and theme updates specifically — the moment a working site is most likely to stop being one.

Changelogs are part of the product

Every release ships with a changelog entry saying what changed. Not “bug fixes and improvements” — what actually changed, so an administrator deciding whether to update at 5pm on a Friday can make that call with real information.