<?php
add_filter( 'auto_update_plugin', '__return_true' );That line opts every plugin on a site into WordPress auto-updates, and for years it was a fair default for quiet sites. After last week it carries a bit more weight: releases that arrive through auto-updates now pass through a review window before they ship.
The change comes from the Protect The Shire post on WordPress.org News. New plugin and theme releases wait up to 24 hours before they go out through auto-updates, so the review team and an AI reviewer named Gandalf can read the diff first. The goal is to cover the whole directory of 78K+ extensions, and the post counts over 3,000 commits to the plugin repository in a single day to show why humans need the help.
What the 24-hour cooldown does
Core releases go through layered review before they ship. Plugin releases haven’t had that, until now: the directory distributed every release the moment a developer pressed the button, and once a plugin was accepted, nothing stood between a bad commit and every site with auto-updates on. The cooldown adds a pause where a bad release can be caught and pulled before it spreads.
What it’s meant to stop looks like the Essential Plugins mess the post links to: someone bought about thirty established plugins, planted a backdoor in all of them, and auto-updates delivered it everywhere. We broke down that cleanup when it happened. A window where every new diff gets scanned targets exactly that pattern. The post also expects the 24 hours to shrink toward minutes as the pipeline matures, so I’d read this as scaffolding while the review tooling catches up.
Sites you update by hand
Mostly it doesn’t reach them. As described, the delay applies to distribution through auto-updates. If you read changelogs, update staging first, and push to production yourself, or run wp plugin update from a cron job, you were never on that channel. Plenty of shops work that way, and for them nothing changes operationally.
For sites that lean on auto-updates, the arithmetic changed. Auto-updating everything used to mean faster fixes with no eye on any release. Now the fast lane has a review step attached, and the balance tips toward trusting it. I wrote about what auto-updates at scale mean for the sites you run before this landed, and that math has moved since.
Which plugins to auto-update
Decide per plugin rather than per site. Small utilities with one narrow job get automatic updates. Anything that owns checkout, page rendering, or a migration path waits for a human: payment gateways, page builders, multilingual plugins, anything with template overrides in your theme. Those break through site-specific interactions a diff review can’t predict.
The filter receives the plugin object, so the policy is short:
<?php
add_filter( 'auto_update_plugin', 'bbioon_auto_update_policy', 10, 2 );
function bbioon_auto_update_policy( $update, $item ) {
$hold = array( 'woocommerce', 'elementor', 'sitepress-multilingual-cms' );
if ( isset( $item->slug ) && in_array( $item->slug, $hold, true ) ) {
return false;
}
return $update; // everything else follows the normal decision
}Keep it in a small must-use plugin rather than functions.php, so a theme switch doesn’t silently change your update policy. The auto_update_$type filters are documented in the Advanced Administration handbook, along with the per-slug pattern.
When the held-back update is a security fix
The delay cuts both ways. A one-day wait on a backdoored release is cheap; the same wait on a patch for an actively exploited bug is expensive. The post itself calls 2026 a year of tension between updating fast to stay secure and holding back to stay secure. The directory has 69 plugins on more than a million sites each, out of over 400M installs, so one held patch leaves a lot of sites exposed while attackers read changelogs too.
Two practical notes. The post describes the delay as applying to auto-updates, so if you push a critical update manually, check which version the directory is serving before you tell a client they’re patched. I haven’t seen that edge case documented yet. And premium plugins update through their own license servers, so WooCommerce.com or Envato items get none of this either way. The plugin review team never had jurisdiction there.
What to check before you change anything
Don’t flip every site to auto-update on the strength of one announcement. Pick one low-stakes site, enable it for a handful of plugins, and watch a week of update emails. Confirm those emails reach a human. And if a site has no staging copy and no recent backup, fix that first. The cooldown reviews the plugin’s code; a release can pass review and still break something on your site.
If you want a hand writing an update policy like this for client stores, deciding what can update itself and what needs a staging pass first, that’s work I take on regularly.
The delay will keep shrinking, but the split stays: the directory reviews releases, and you decide per plugin which ones you trust. Write that list down somewhere, because the default changed last week.
