v1.29.0
Update Policy answers in Site Health
A hold is a missing update, and a missing update is what someone sees when they go looking for a problem. The module already explained itself on the Updates screen and the dashboard. Site Health is the third place people ask, and it was silent there.
One entry, three answers:
- A release is being held — reported as passing, not as a fault. Names the release, the date this site first saw it, and the date the hold ends.
- Nothing is being held — also worth saying. "The policy is on and holding nothing" is the reading that stops somebody hunting for a hold that was never there.
- The hold is set to zero days — raised as a recommendation. It is the one setting that contradicts the Modules screen: switched on, doing nothing it claims to.
On a network the entry appears only where core updates are actually administered. A subsite decides nothing here, so it is told nothing.
The hold gets the last word on unattended updates
Major core auto-updates are off by default, so the module's refusal has always been belt and braces — but a site that turned them on should not quietly bypass a hold. That refusal now runs late.
Other update plugins hook the same decision at a high priority precisely so their answer is the last one, and a plugin arguing for an update beats one arguing against it by merely running later. The hold would have survived that argument anyway, because the held release is removed from the update offer and there is then nothing left to authorise. This makes the agreement explicit rather than incidental — while still leaving a site able to take the last word back from its own mu-plugin.
Under the hood
The test harness now models hook priority and removes a named callback rather than every callback on a hook. Without that, a test of the priority would have passed whatever number the module used; the assertion that carries the weight now puts a competing filter against this one and watches which wins.
No settings change, nothing to migrate.