The usual advice for a patch release is to click update and move on, and mostly that works here. I’d still slow down for WooCommerce 10.8.1, because one of its two fixes deals with a failure mode that applies to every plugin with upgrade code, including yours. It went out on May 28, 2026, announced on the WooCommerce developer blog, and patches two regressions that arrived in 10.8.0.
One fix is routine. The other one changes how you should write code that runs during an update.
What broke in 10.8.0
The first regression is admin JavaScript. 10.8.0 upgraded the downshift package, and the behavior change broke the CustomSelectControl component WooPayments uses in onboarding. The legal entity type dropdown crashed, so a new merchant going through NOX-based onboarding could not get past that step. Stores that finished onboarding long ago never saw it, which is also why regressions like this slip out: the people testing them already have working accounts. 10.8.1 restores compatibility and adds a regression test.
The second regression is in PHP, and it’s why I’m writing this. Some merchants updating in place from 10.7 to 10.8 saw Uncaught Error: Class 'Automattic\WooCommerce\Enums\DefaultCustomerAddress' not found logged from class-wc-settings-general.php. The enum is new in 10.8, the general settings screen references it, and in the middle of the update the autoloader could not resolve the class. The upgrade still completed, so stores ended up healthy, and WP-CLI upgrades never hit it. I wrote about what to check first when 10.8 shipped, and this fatal was not something you could check from a staging copy.
The part of the 10.8.1 fix worth copying
An in-place plugin update happens at an odd point in a request. WordPress replaces the plugin directory while code loaded from the old files keeps executing. The autoloader registered at bootstrap may map class names to files that no longer exist, and the new files on disk are not registered with it at all. If the running code references a class that only exists in the new version, autoload fails and PHP throws the fatal. That is what happened in class-wc-settings-general.php, and the fix was a defensive class load before the enum gets used. The same pattern belongs in any upgrade routine you ship:
function bbioon_upgrade_2_1_0() {
$current = get_option( 'bbioon_version' );
if ( version_compare( $current, '2.1.0', '>=' ) ) {
return;
}
// The autoloader may still describe the pre-update plugin here.
if ( ! class_exists( 'Bbioon\Enums\CustomerDefault' ) ) {
require_once __DIR__ . '/enums/CustomerDefault.php';
}
update_option( 'bbioon_customer_default', Bbioon\Enums\CustomerDefault::Store->value );
update_option( 'bbioon_version', '2.1.0' );
}class_exists() runs the autoloader by default, so the manual require_once only fires when autoloading cannot find the class. That is the state you are in mid-update. The PHP manual collects years of edge-case notes on this, including classes loaded inside an autoload chain not counting as declared until the chain finishes. Mid-update code runs into those edge cases, because the usual guarantees about what is loaded do not apply. I doubt I would have caught it in testing either; a staging update rarely reproduces the timing of a live admin request.
If you ship a plugin with upgrade routines and want someone to look at the load order before the next release, I do that kind of review regularly. It costs less than a day of broken updates.
How I’d handle this on stores I manage
On any store that was on 10.7 when 10.8 rolled out, search the log for DefaultCustomerAddress before telling the client everything is fine. The upgrade completed, so the store is usually healthy, but a fatal sitting next to a version bump reads as breakage to a store owner, and hosts that email on fatal errors will escalate it into a ticket on their own.
For the next round, run wp plugin update woocommerce from the terminal. The release notes confirm CLI upgrades never hit the race, and it matches how I prefer major plugin updates anyway: run them where you can see the output, rather than from an admin screen that reloads itself mid-swap. The same applies if you leave auto-updates on for these, which I covered in what WordPress auto-updates at scale mean for the sites you run.
One thing to do today: run wp plugin get woocommerce --field=version on the stores you watch, confirm it prints 10.8.1, then grep the debug log for DefaultCustomerAddress. If the string shows up, you have the explanation ready in one line before anyone asks.
