A client called me last week. They run a busy WooCommerce store, roughly 15k SKUs, with a very custom block-based checkout. They had seen the announcement for the WordPress 6.9 Release Candidate 3 and decided, in the name of being “proactive,” to hit the update button on their live production server. Ten minutes later the checkout was throwing 500 errors, because a block they had customized leaned on a data attribute that changed in 6.9. They had assumed a point release was a minor tweak. It wasn’t.
Getting to RC3 is a real milestone for the community, but an RC is still software under development. That is what I told the client: it exists so people can test it, not so it can run the site that pays their bills. The WordPress 6.9 testing phase deserves the same caution you would give any other unvetted core change. Your production database is not the place to improvise.
My own first instinct on that broken checkout was to drop a quick filter into the theme’s functions.php and bypass the validation error until the official release landed. It worked for about five minutes. Then I noticed the same filter was stopping tax calculations from firing. I had done exactly what I tell other people not to do: patch a core bug on a live site instead of rolling back to a stable version and moving the testing to a staging environment.
Testing WordPress 6.9 without wrecking a live site
If you want to help the community and keep your clients out of trouble, do the testing somewhere disposable. The official notes on the WordPress News site list four ways to get RC3 running. I reach for WP-CLI because it is fast and it keeps me out of a dashboard that may already be half broken. Run wp core update --version=6.9-RC3 on a local dev environment and watch what your custom hooks do.
The 6.9 Field Guide is where the useful detail sits. If you write code, read the Gutenberg commits and the Trac tickets it points to. That is where the quieter block editor and REST API changes turn up, the ones that take out a custom integration without warning. An hour with those notes now is cheaper than a twelve-hour Sunday shift later.
/**
* A simple utility to prevent beta/RC updates on production
* and log environment-specific data for testing.
*/
function bbioon_protect_production_environment() {
if ( defined( 'WP_ENVIRONMENT_TYPE' ) && 'production' === WP_ENVIRONMENT_TYPE ) {
// Just a safety check to ensure we aren't running dev logic here
return;
}
// Logic for staging/local testing with WordPress 6.9 RC3
error_log( 'bbioon: Running compatibility check on ' . get_bloginfo( 'version' ) );
}
add_action( 'admin_init', 'bbioon_protect_production_environment' );Theme and plugin authors are in the final stretch. If you have not checked your “Tested up to” headers yet, do it now, and do it in a sandbox. WordPress Playground gives you an instance in the browser, so you can break things without consequences and without standing up a whole local site first.
What I tell clients instead
There is more going on here than “don’t update production.” It helps to know where you are sitting in the release cycle. RC3 is the last call for major bug reports before the release scheduled for December 2, 2025. The short version:
- An RC does not belong on a mission-critical site, ever.
- WP-CLI and the Beta Tester plugin are for staging and local, nowhere else.
- Check your “Tested up to” versions this week, not on release day.
- Found a bug? File it in the Alpha/Beta area of the support forums rather than sitting on it.
This gets complicated fast once custom APIs or heavy WooCommerce workflows are in play. If you would rather not spend the next core update debugging someone else’s mess, drop my team a line. We have probably seen it before.
So which is it for you this week: a local build to test 6.9, or waiting for the final release to see what breaks?
