Skip to content

v1.24.0

Choose a tag to compare

@BenKalsky BenKalsky released this 20 Aug 21:34
· 17 commits to main since this release
9dfdaa8

Two releases in one: 1.23.0 was merged but never published, and its changes are all here.

New module: Update Policy

On 2026-08-20 every Digitizer site running WP Rocket broke at once. The plugin had not changed; WordPress had. WordPress 7.1 turned a latent type error in WP Rocket's Cloudflare integration into a fatal, and WP Media shipped the fix within days. A site that had taken 7.1 a month later would never have seen it.

That is a timing failure, not a caching one. Nothing on those sites held an opinion about when a major release should be installed, because WordPress has no such setting — it has a switch for unattended major updates, and nothing at all for the button a human presses.

This module holds a major release back for a set number of days — 30 by default — after the site is first offered it, then gets out of the way.

  • Security and maintenance releases are never held. They are what keeps a site alive, WordPress installs them on its own, and this does not look at them.
  • A held release is removed from the offer, not merely discouraged. A warning does not stop someone pressing the button; a button that is not there does.
  • The hold is visible, dated and reversible. The Updates screen says which release is held, when this site first saw it, when the hold ends, and offers a control that lifts it permanently for that release line.
  • Nothing is ever installed automatically. When the window passes the release is simply offered again. Automatic major updates across a fleet of client sites are not a default this plugin will set.
  • The window is counted from the day this site first saw the release rather than the day it was published: no external service is asked, and every site checks twice a day.
  • On a multisite network the policy belongs to the main site, and only a network administrator can switch it on or off — a switch that decides for a whole network asks for the authority that decision needs.

Design: docs/superpowers/specs/2026-08-20-update-policy-module-design.md.

Onboarding reports updates for its GitHub items (was 1.23.0)

The Hello Digitizer child theme, Elementor MCP and MCP Adapter are not in the WordPress.org directory, and the wizard installs the two plugins inactive — so their own code never runs and nothing on the site ever checked them for a new version. They sat at whatever version they were installed at.

While the Onboarding module is enabled, WordPress is now told about their releases, so they appear on the Plugins and Themes screens like anything else and can be updated with the usual button. Because of that they can be enrolled in automatic updates too, which the wizard previously refused them.

Four things keep it safe: an answer another source already provided is never overwritten; items that are current are recorded as up to date rather than left out, which is what lets WordPress offer them auto-updates at all; nothing is ever fetched from a visitor's page load, only during WordPress's own update check; and a release is only ever an upgrade, from a built archive with a readable tag.

Onboarding enrols the plugin itself (was 1.22.0, already published)

Unchanged here, and listed for completeness.

Verification

437 assertions across eight stub harnesses, php -l and node --check clean, the four Plugin Check security sniffs at zero, Hebrew catalog at 621 strings with nothing orphaned or missing. Eleven review rounds across the two pull requests, twelve findings, all real.