WordPress turned 23 this week, and the anniversary post on WordPress.org News has one number in it that matters to anyone maintaining sites: 46% of all installs were already on 7.0 within seven days of the release. Matt Mullenweg’s WP23 post is where that figure comes from, pulled from the WordPress stats page, and he frames it as an update that rolled out with no breakage. From a developer’s side it looks different. WordPress auto-updates just ran a rolling deploy across tens of millions of servers, and most of the people hosting those servers opted in years ago without ever deciding anything.
WordPress at 23 is simultaneously both the strongest and most precarious it’s ever been.
That line cuts both ways, and I think it’s the most honest sentence in the post. Twenty-three years of backwards compatibility discipline is why a number like 46% doesn’t end in disaster. It also means “the site updates itself” is your release process now, whether you wrote one or not.
Why WordPress auto-updates are now your release process
First, something to know if you inherited sites rather than built them. Since WordPress 5.6, new installs enable automatic updates for major versions by default. Sites created before that, or where someone clicked the toggle under Dashboard, Updates, may still be minor-only. Across a batch of client sites you can easily have both behaviors running at once, and the Advanced Administration Handbook documents which constant and which toggle wins in each case.
Second, when something breaks after a major lands, it’s rarely core. It’s usually a plugin still calling a deprecated function, or a theme template that assumed markup core finally removed. So after any auto-update, the useful question is which plugins on the site still behave like it’s 2021. That’s also why “no breakage” can be true for core and still mean very little for your particular stack.
For context, we followed the 7.0 cycle here when the release was paused, and what shipped as Armstrong is a normal major by the standards of the last few years. I mention it because anniversary posts make releases sound bigger than the diff actually is.
The wrong fix: switching updates off
When a client asks about surprise updates, the usual reflex is to kill WordPress auto-updates everywhere. Someone drops a kill switch into wp-config.php on every site they touch and calls it solved.
<?php
// wp-config.php, don't do this
define( 'AUTOMATIC_UPDATER_DISABLED', true );
// and not this either
define( 'WP_AUTO_UPDATE_CORE', false );The problem is that neither setting tells a major apart from a security release. When WordPress 6.9.2 shipped ten vulnerability fixes, the sites with updates switched off stayed exposed until somebody remembered them. You get rid of an annoyance and pick up a real security risk in exchange.
DISALLOW_FILE_MODS goes wrong in a different way. It stops background updates, but it also blocks plugin and theme installs and manual updates from the admin, so every maintenance task takes longer. Some hardened setups want exactly that. As an update policy, though, it just means falling behind more slowly.
What I’d put in place instead
Keep minors automatic everywhere, no exceptions. Minors are security and maintenance releases, and skipping them is riskier than installing them. Set it explicitly so host defaults don’t decide for you:
<?php
// wp-config.php
define( 'WP_AUTO_UPDATE_CORE', 'minor' ); // majors stay a deliberate choiceTreat majors as a decision. On a copy of the site with WP-CLI it takes about ten minutes: run wp core update, then wp plugin list --update=available to see what’s stale, then click through the two or three flows that make the client money. If those pass, switch the production site to majors and let the next one roll in on its own. After a major lands in production, wp core version confirms it, and a look at debug.log plus the homepage and checkout catches plugin conflicts while they’re still small.
For sites where you leave majors on, you should know when they ran. WordPress only emails the admin when a background update fails, and no email tells you nothing if nobody reads that inbox. The automatic_updates_complete action fires with the results of every run, so a short mu-plugin can turn it into a line in whatever log you already watch:
<?php
add_action( 'automatic_updates_complete', 'bbioon_note_auto_updates' );
function bbioon_note_auto_updates( $results ) {
foreach ( (array) $results as $type => $updates ) {
foreach ( (array) $updates as $update ) {
$version = $update->item->current ?? '';
$failed = is_wp_error( $update->result );
// write $type, $version, $failed to your log or Slack
}
}
}The last piece is less about updates and more about dependencies. The WP23 post also says the WP Engine litigation has moved on to attempting to dissolve the WordPress Foundation, the nonprofit that holds the trademark and supports WordCamps and open source education. I can’t predict how that ends and I won’t build a client strategy on a guess. It is a good excuse to make deploys stop depending on any single upstream server having a good day: pin plugin versions, keep copies of what you ship in storage you control, and pull from your own artifact store at build time instead of fetching live from the plugin directory. That was good practice for WooCommerce stores before any of this, because a plugin update can remove a payment method or a shortcode just as easily as a core update can change markup.
None of this means turning majors on everywhere. If you run multisite I’m not sure the no-breakage numbers describe your setup at all, and heavily customized stores usually deserve one deliberate staging pass per release. Try it on the next minor: run it on staging the same day it ships and walk through checkout. You’ll learn more about your own update risk from that than from any release post. And if you want help writing an update policy for a store or a batch of client sites, that’s work I do regularly, so send over the plugin list and we’ll go through it together.
