WooCommerce 10.9.2 Deprecates Push Notifications Flag

Every WooCommerce dot release tells you two things: what broke, and what someone quietly decided is now non-negotiable. WooCommerce 10.9.2 shipped on July 2 and it does both in a single, short changelog. If you skimmed it, you probably saw the words “push notifications” and moved on. That would be a mistake.

I have spent two decades watching agencies get bitten by exactly this kind of release. The one where the headline sounds harmless — a mobile app feature nobody at the office cares about — and the actual payload is a database migration plus a fatal-error guard on the settings SDK. Both of those touch every store in the fleet.

Read it as an operator, not as a reader of release notes. Here is what changed, why it matters, and what I would do about it before the morning stand-up.

What is actually new

WooCommerce 10.9.2 is a dot release with two changes, no security update, and one database update. That is it. The full text of the official release notes is short enough to fit on one screen, and every word carries weight.

The first change is a fix. During in-place upgrades from 10.8.x to 10.9.x some stores hit a fatal error because the legacy WC_Settings_Page code path was calling into new settings SDK classes before the autoloader had caught up. Symptoms looked like a white screen on wp-admin and, in the wild, threw Class 'Automattic\WooCommerce\Admin\Settings\SettingsSectionRegistry' not found. The full reproduction is in issue #66031, filed on June 25 by a merchant who went 10.8.1 → 10.9.1 and lost admin. The fix cited in the release notes is PR #65972: guard the new settings SDK classes with defensive checks and re-add the deprecated Automattic\WooCommerce\Admin\API\Settings class as a no-op compatibility stub so stale REST controller registrations from 10.8 instantiate safely instead of exploding.

The second change is a policy decision dressed as a bullet point. PR #66088 — “Always enable push notifications by deprecating the feature flag”, authored by Hannah Tinkler and merged July 1 — removes the feature flag from the FeaturesController entirely. The feature now returns true regardless of the stored option value. A new database migration, wc_update_10902_remove_deprecated_push_notifications_option, runs on upgrade and deletes the stale option row that some stores were still holding from the 10.5.0 autoload migration. The single remaining escape hatch is a filter: woocommerce_enhanced_push_notifications_disabled, defaulting to false, boolean-coerced.

Context matters here. Enhanced push notifications shipped as the default in 10.9.0 back on June 23, but as the 10.9.2 notes spell out, stores that had switched the flag off during the beta window kept it off through the upgrade. 10.9.2 closes that gap. The feature itself, documented on woocommerce.com/document/woo-mobile-notifications, lets the Woo mobile app 24.9+ pipe order, stock and review notifications straight from the store without Jetpack sitting in the middle. Merchants get thresholds — high-value order minimums, low-rating review ceilings — instead of an all-or-nothing firehose.

Why it matters for WordPress and WooCommerce people

Two audiences should care, for different reasons.

Agencies running a fleet should treat 10.9.2 as a mandatory upgrade, not a nice-to-have. The fatal-error guard is exactly the class of fix that turns a routine Tuesday-night update into a two-hour incident, because the failure happens on wp-admin — the surface you use to notice something is wrong. If your update playbook still involves clicking “Update” on production and hoping, this release is a good excuse to change that playbook. Move to staged rollouts, keep 10.9.0 or 10.9.1 stores on a short leash, and bounce opcache after core plugin updates.

Extension authors and anyone who was relying on the internal Automattic\WooCommerce\Admin\API\Settings class need to notice the phrasing. WooCommerce is telling you, in a release-notes bullet, that they removed a legacy REST controller and kept a compatibility stub only because deleting it caused fatals during upgrade. That stub is not a stable surface. It is life support. If your plugin is instantiating that class, refactor now, before 11.0 on July 28 takes the stub with it. The same discipline applies to anything touching the pre-SDK settings paths — WooCommerce is clearly mid-migration, and the mid-migration window is where third-party code gets stranded.

Store owners with a mobile-first operations team should also pay attention. If your store was on 10.9.0 with push notifications intentionally disabled, that disable is about to become inert on upgrade. The migration wipes the option; the FeaturesController no longer reads it. Your only supported way to keep the feature off from 10.9.2 onwards is to add a filter to woocommerce_enhanced_push_notifications_disabled. If you skip that step, on the next merchant login through the Woo mobile app the store will happily start firing notifications you did not consent to. That is not catastrophic, but it is embarrassing to explain to a client who asked for silence.

What I would do (or not do) about it

Three concrete moves.

First, run the upgrade on staging with the actual production database. The database migration is small and idempotent, but the fatal-error class of bug in 10.9.1 taught us that WooCommerce upgrade paths from 10.8.x carry surprises that only show up under real class autoloader state. A fresh install of 10.9.2 is not a test; a copy-of-production is. Verify wp-admin loads, verify the settings tabs render, then push to production.

Second, decide the push-notifications policy per store, in code, not in the UI. Do not leave this to whatever the current option value happens to be after migration. For stores where you want the feature: do nothing, ship 10.9.2, move on. For stores where the client explicitly asked for silence: drop a one-liner mu-plugin that returns true from woocommerce_enhanced_push_notifications_disabled. Version-controlled, reviewable, survives future upgrades. Do not lean on a UI toggle for this — WooCommerce just proved that they will remove the toggle underneath you.

Third, audit your codebase for any lingering references to the pre-SDK settings namespaces. If you or a plugin you maintain instantiates Automattic\WooCommerce\Admin\API\Settings directly, or extends internal settings classes that are not part of the documented API, plan the refactor for the current 10.9 window rather than the 11.0 window. The stub in 10.9.2 is a runway, and it is short. WooCommerce 11.0 lands on July 28, along with the removal of the block-based product editor beta and product object caching enabled by default. That is not a release where you want to also be discovering a settings-class regression the day after upgrade.

Everything else in 10.9.2 is quiet. That is the point. Dot releases like this one are the price of running the maturity layer — the redirections, the migrations, the compatibility stubs, the filter-shaped escape hatches. Nobody talks about them in the keynote, and they are exactly what makes WooCommerce keep running on the day your first ten thousand shoppers arrive.

Update the fleet, drop the filter where you need it, and move on to the 11.0 planning.