A client rang me last night in a panic. They had hit “Update” on their production site the moment WordPress 6.9 went live, and five minutes later their main landing page, which leans on some heavy custom block filters, was rendering like a CSS explosion in a Lego factory. They wanted it fixed right then, which in practice means making it worse before it gets better.
My first instinct, and the client’s demand, was a full rollback. That was off the table: database migrations for three of their critical plugins had already run, so reverting the core files without a granular database restore would have wiped six hours of holiday sales data. We ended up patching the block compatibility on the fly with the site still live. It was ugly, and none of it would have happened under a sane WordPress core updates policy.
What the 6.9.1 planning tells you
The Dev Chat Agenda from December 10 shows how fast the core team is moving. WordPress 6.9 is barely out and Gutenberg 22.2 is already being integrated. @jorbin has also flagged the need for 6.9.1 planning, with a debate over whether to ship a maintenance release immediately or wait until after the New Year.
When contributors are discussing a maintenance release before the new smell has worn off the major version, that is your cue to slow down. Major releases carry architectural shifts, and 6.9 changes how Gutenberg interacts with the rest of the site. If you run a complex WooCommerce store, or a site with a lot of custom block development, you are the edge case nobody has tested yet.
Managing updates without the heartburn
For a production environment, decouple your update schedule from the public release date. Take the security patches and the minor bug fixes as they land. Hold the major version bumps until the point-one release. Here is the snippet I use so clients can’t pull the trigger on a major core update before I have vetted it in staging.
/**
* Control core updates to avoid major version jumps on production.
* This allows minor updates (e.g., 6.8.1 to 6.8.2) but prevents 6.8 to 6.9.
*/
add_filter( 'allow_major_auto_core_updates', 'bbioon_limit_major_updates', 10, 1 );
function bbioon_limit_major_updates( $allow ) {
// Only allow major updates in staging environments
if ( defined( 'WP_ENVIRONMENT_TYPE' ) && 'staging' === WP_ENVIRONMENT_TYPE ) {
return true;
}
return false;
}
/**
* Filter to specifically target the update nag for non-admins
*/
add_action( 'admin_head', function() {
if ( ! current_user_can( 'update_core' ) ) {
remove_action( 'admin_notices', 'update_nag', 3 );
}
}, 1 );Keeping major updates in staging gives the community and the core team time to find the edge cases. The 6.9.1 discussion in the dev chat is where those tickets get resolved. Better that than having your site be the reason one gets opened.
Don’t be the guinea pig
I like new features as much as anyone, but I like my sleep more. 6.9.1 planning being on the agenda this early says plenty about how finished a major release is on day one. My checklist for the next month:
- Wait for 6.9.1: unless you need a specific feature to keep the site running, hold off until the first maintenance patch.
- Read the dev chat: the Slack meetings show which components are currently fragile.
- Mind the Gutenberg gap: Gutenberg 22.2 is out, so test your custom blocks against the plugin version before the core update reaches you.
Update triage is a bad way to spend an evening. If you would rather someone else owned your update schedule, get in touch with my team. We have probably seen your version of it already.
Are you seeing problems with the 6.9 rollout, or holding off until January? The comments are open.
