WooCommerce 10.x development is moving fast, but the latest post on the official developer blog caught my eye for a different reason. WooCommerce.com itself now runs on Nightly WC Core. If you’ve ever had a site fall over after a minor update because of some odd Action Scheduler race condition, you’ll see why this matters for everyone building on Woo.
I’ve spent 14 years dealing with production environments, and the usual advice is “stay on stable.” But when you’re the ones building the core software, you should be running it yourself. Moving WCCOM, a store that processes real payments, onto Nightly WC Core means the team catches breaking changes before the general public ever sees them.
The AI-driven pipeline
Updating a production store every weekday by hand would be miserable. So they built a CI/CD pipeline that hands the messy parts of deployment to AI, mainly patch replays. WCCOM runs a slightly customized version of core, so an AI agent reads the Nightly WC Core diff, checks it against their patch manifest, and decides whether each fix is still needed or has already been merged upstream.
There’s also an advisory AI pass over the core diffs, which run to thousands of lines. No human developer is going to give a 10,000-line diff a meaningful review every morning. The AI looks for the places where Core touches the WCCOM codebase and flags the risky ones.
<?php
/**
* bbioon_check_core_compatibility
* A defensive check for nightly or beta core functions
*/
function bbioon_check_core_compatibility() {
// If we're living on the edge with Nightly WC Core,
// we need to be defensive about new APIs.
if ( ! function_exists( 'wc_get_new_experimental_feature' ) ) {
error_log( 'Nightly API missing: wc_get_new_experimental_feature' );
return false;
}
return wc_get_new_experimental_feature();
}
The 15GB index gotcha
Within two weeks of the switch, they hit a real bottleneck. An upstream PR dropped a composite index on the wp_wc_orders_meta table. On its own the change looked fine, since Core wasn’t using that index. On WooCommerce.com, where that index alone is 15GB, it was a disaster.
Third-party extensions like WooPayments relied on that index for subscription renewals. Without it, queries that used to take milliseconds scanned millions of rows and timed out at 34 seconds. Because the store was on Nightly WC Core, the team caught the regression and mitigated it before it could ship in version 10.8. This is the kind of problem good testing tools exist to catch.
What this means for developers
If you build extensions, this is good news. The “stable” releases you download should actually be stable. If you contribute to core, your code lands on a production store within 24 hours of merging to trunk. The stakes are high, but I don’t see another way to build a platform that takes performance seriously.
If keeping up with Nightly WC Core changes is eating your dev hours, I can take it off your plate. I’ve worked with WordPress since the 4.x days, and I know how to refactor legacy code without breaking your checkout flow.
Final takeaway
Running a production store on a nightly release cadence takes serious telemetry. With AI code reviews and real-time slow-query monitoring in place, the Woo team has moved from “hope it works” to “prove it works at scale,” and I’d like to see more large WordPress sites run this way.
The WooCommerce GitHub repo and the Action Scheduler documentation show how these background processes are changing. For the technical details, the original WooCommerce Developer Blog post has the full breakdown of their AI prompts and telemetry stack.
