Sudo v4.9.2

Research prototype. Tags are reproducible research snapshots for disposable local environments and WordPress Playground, not production-readiness declarations.

The reauthentication-usability release. 4.9.0 removed automatic replay to close a real vulnerability; the convenience cost landed harder than its notes conveyed. This release pays down the two parts of that cost that were defects rather than tradeoffs.

No migration. No stored format change. Existing sudo sessions are unaffected.

Settings → General no longer challenges a save that changed nothing

The options.critical rule gated on a critical field being present in the POST, and that screen posts the critical fields alongside ordinary ones. Editing only the site title, tagline or timezone therefore raised a challenge — and after the 4.9.0 confirmation work it showed the label "Change critical site setting" with no Target line at all.

It now challenges only when a submitted value differs from the value already stored.

Behaviour change worth reading if you subscribe to audit hooks: a General Settings save touching nothing critical now fires no wp_sudo_action_gated event, so anything using that hook as a "someone was on the dangerous settings screen" tripwire loses that signal. The comparison fails toward challenging on every uncertainty.

The post-reauthentication notice now says something true on every path

Every clause of the old copy was wrong somewhere:

• It opened "Reauthentication complete." — true only where a credential was actually verified on that request, and false on the two paths where the user already held a session.
• It said "review the form and submit it again" — but since 4.9.0 the commonest arrival is a link-driven action like plugin or theme activation, which has no form.
• Its secrets variant named "password and secret fields", implying the other fields were saved. Nothing is replayed; the whole request was discarded.

One notice now covers every path, states plainly that nothing was changed, and says the sudo session will carry the retry through. It carries role="alert", so a screen-reader user is told their action was discarded — previously that announcement never happened at all.

Also in this release

• wp_sudo_require() reports its inert return_url argument through _deprecated_argument() (#461).
• The handler/usable-screen guard now asserts its two classifications are disjoint (#434).

Known limitation

Reauthentication in the browser admin is still worse than before 4.9.0. Three of the four problems reported in 4.9.1 are fixed here (#469, #463, #445). What remains is the largest: a gated form still returns you to the correct screen with your unsaved edits gone, repopulated from what is stored rather than from what you typed (#436 face 1).

Two further improvements are tracked and not attempted here: naming every rule a form's changes matched rather than only the first (#436 face 3), and gating before the form is offered (#436 face 4) — which would dissolve the problem rather than improve recovery, and is the most valuable of the three.

Verification

1,307 unit tests, 3,904 assertions. PHPStan level 6 and Psalm clean. Upstream WordPress claims verified against WordPress 7.0.1 and wordpress-develop trunk, and machine-rechecked by composer verify:sources (67 registered citations).

The pre-tag external-claim audit added four entries to docs/llm-lies-log.md (#78–#81). All four were prose about code that was itself correct — none would have changed behaviour, and none was catchable by the test suite, PHPStan, Psalm, or metrics.