I recently worked with a client who runs a pretty intense photography marketplace. He likes to live on the edge, so he was running a pre-release build of WordPress to get a head start on some new block features. One morning I got a frantic Slack message: “Ahmad, I can’t publish anything. The button is there, but nothing happens.” After digging through the console and tracing the hooks, I found it wasn’t his custom code at all. It was a core bug where hidden async-upload fields were being marked as ‘required,’ which quietly killed the publishing flow. That is the kind of thing being squashed in the latest WordPress 6.9 core updates.
My first idea was to write a quick filter that bypassed validation on those fields. Classic dev move, patching the symptom instead of the cause. Then it occurred to me that messing with core field requirements in the REST API during a version transition is like playing Jenga with a toddler. So we tracked the release candidate instead. If you follow the source at make.wordpress.org/core/2025/12/01/wordpress-6-9-release-candidate-4/, you’ll see RC4 addresses this specifically under ticket #64305.
Bugs squashed in the WordPress 6.9 core updates
One of the quietest and most dangerous fixes in this release involves _wp_cron(). On sites using ALTERNATE_WP_CRON, running cron during the shutdown hook could break the site outright. On a busy WooCommerce store that takes out scheduled emails and inventory syncs, and production is a terrible place to learn about it.
/**
* A safer way to ensure your custom tasks are hooked correctly
* until the core fix is fully rolled out.
*/
function bbioon_check_cron_compatibility() {
if ( defined( 'ALTERNATE_WP_CRON' ) && ALTERNATE_WP_CRON ) {
// Log or handle specific logic for high-traffic environments
error_log( 'BBIOON: Monitoring alternate cron behavior.' );
}
}
add_action( 'init', 'bbioon_check_cron_compatibility' );RC4 also fixes REST API error handling. Updating a setting that doesn’t exist used to return a ‘success’ status, which is a real headache for headless setups or anything built on top of the API. Details like that decide whether an integration can trust what it hears back. The official WordPress core blog carries the full list of changes, but these are the ones likely to save you during the next update cycle.
So, what’s the takeaway?
Pay attention to the release candidates, and for heaven’s sake, don’t test them on the site that pays your bills. WordPress 6.9 is shaping up well, especially with the added ability to hide blocks, but it needs a disciplined testing process behind it. Without a staging environment or the WordPress Playground to vet these changes, you are signing up for an emergency weekend call.
This stuff gets complicated fast. If you are tired of debugging someone else’s mess and just want the site to work, drop my team a line. We have probably seen it before.
If you are still patching core bugs by hand, the fix is a testing workflow rather than one more filter.
