This commit is contained in:
Javier Casares 2026-09-23 06:11:14 +00:00
commit bb3beaa353
12 changed files with 465 additions and 147 deletions

View file

@ -1,5 +1,48 @@
== Changelog ==
= 1.9.1 =
_Release date: 2026-09-23_
**Changed**
* Maintenance pass over the 1.9.0 security-patch feature: `composer update` (no changes — dependencies already current, no known CVEs), full code + security review of the 1.9.0 diff (clean-context pre-deploy audit: escaping, capability gating, CSRF, and the 1.8.1 updater invariants all verified correct; its two suggestions were applied — see below), and floors re-verified.
* Pre-deploy audit hardening: `security_patch_for()` only accepts declarations that strictly increase the version — a store typo (self-mapping or downgrade) can no longer produce a downgrade/re-install "update" notice; the `version` argument in premium/free package URLs is now `rawurlencode`d, matching the installer. POT regenerated at 1.9.1.
**Compatibility**
* WordPress: 4.4 - 7.1 (scan-verified 2026-09-23: wp-compat ladder clean at 4.4 through 4.7; no WordPress API newer than 4.4 in use; the dev environment here runs WordPress 7.2-alpha trunk with the suite green, but 7.2 is not GA and `Tested up to` stays at the AGENTS window top)
* PHP: 8.0 - 8.5 (scan-verified 2026-09-23: PHPCompatibility ladder 5.6-8.5 — scan-clean from 7.4; manual audit keeps the real floor at 8.0: `mixed` hints, `str_contains()`, `str_starts_with()`)
**Tests**
* PHPCS (WordPress-Core, WordPress-Docs, WordPress-Extra): pass
* PHPStan max (level 10) + wp-compat: pass
* PHPUnit: 158 tests, 423 assertions (also green against WordPress 7.2-alpha trunk / test library rebuilt from wordpress-develop master)
= 1.9.0 =
_Release date: 2026-09-22_
**Added**
* Security-update notices (with Core 1.16.0+): when the store declares a security patch for the exact version this site runs (e.g. 1.2.3.1 applies to 1.2.3), Manager shows a red "Security update available: %name% (vX → vY) — Update now" notice on its catalog page **and** on the Plugins screen, and the catalog row status reads "Security update available (vX → vY)". The Update action installs the declared patch — never the feature mainline — so sites receive the security fix without being pushed across feature versions.
* The native update integration (update badge, `wp plugin update`, auto-updates) also targets the declared patch: the injected update entry carries the patch version and a versioned, authenticated package URL. Patches declared for other versions never apply (exact match on the installed version). Chained patches work (1.2.3.1 → 1.2.3.2 once declared).
* Spanish (es_ES) and Catalan (ca) translations for the new strings; POT regenerated.
**Requires Core 1.16.0+ on the store** for patch data and versioned downloads (older Core: the catalog simply carries no patches and Manager behaves as before).
**Tests**
* PHPCS (WordPress-Core, WordPress-Docs, WordPress-Extra): pass
* PHPStan max (level 10) + wp-compat: pass
* PHPUnit: 157 tests, 420 assertions
**Compatibility**
* WordPress: 4.4 - 7.1 (unchanged)
* PHP: 8.0 - 8.5 (unchanged)
= 1.8.1 =
_Release date: 2026-09-22_