WooCommerce Product Editor Retirement Lands in 11.0

I spent the early hours of today doing what I usually do on a Sunday: reading release notes with a strong coffee. The one I kept circling back to was not a flashy feature drop. It was a quiet, surgical advisory from the WooCommerce team. After four years of beta, the block-based product editor is being retired. The classic product editor stays. That is a meaningful sentence, and not the one most people expected.

I have lived through a few of these. Twenty years of WordPress teaches you that the boring announcements are usually the important ones. A feature toggle disappears, a package is deleted, and a thousand custom integrations need to be checked. If you ship WooCommerce stores for a living, this is one of those weeks where you owe yourself an hour with the codebase.

So here is what I read, what it means, and what I would actually do about it before WooCommerce 11.0 ships on July 28.

What is actually new

On June 2, the WooCommerce developer blog published an advisory titled The product editor beta is being retired in WooCommerce 11.0. The plan is staged. WooCommerce 10.9, which ships on June 23 according to the 10.9 beta post, introduces in-product deprecation notices, a one-click revert path back to the classic editor, and developer warnings on the affected code paths. WooCommerce 11.0, scheduled for July 28 per issue #65319, deletes the @woocommerce/product-editor package, the block-editor product page, the feature toggle in Settings, the related routes and admin menu entries, and the supporting tests.

What is not changing is the data. Product objects, meta, taxonomies, and Custom Fields are untouched. Stores using the beta editor revert to the classic editor without a migration step and keep editing the same products in the same database tables. There is no media reflow, no schema change, no Action Scheduler queue to babysit. The retirement is a UI rollback, not a data event.

Extension authors are the group that needs to read carefully. The deprecation advisory and the linked issue #65318 for the 10.9 deprecation pass call out three specific things to audit in your codebase: any import or reference to @woocommerce/product-editor, any usage of product-block-editor-v1, and anything marked __experimental in the product editor public API. These will throw deprecation warnings in 10.9 and stop existing entirely in 11.0.

For context, this is the second time the team has signalled this direction. The original strategic shift away from a custom block-based editor in favour of consolidating around Gutenberg primitives was communicated back in 2024. June’s posts are the operational follow-through, not a surprise pivot.

Why it matters for WordPress and WooCommerce people

If you run a store, the practical impact depends on a single question: did anyone in your team ever switch on the “Try the new product editor” toggle in Settings? If the answer is no, your June 23 update is uneventful. You will not see the deprecation banner, because the banner only appears for stores actively using the beta. Your team will keep editing products the way they have always done it, and the July 28 update will simply delete code paths you never used.

If the answer is yes, and especially if a workflow in your store relies on a custom field or a third-party extension that only ships a block-editor sidebar, then 10.9 is your warning shot. The banner is a feature, not a nag. Revert before 11.0 lands so your team is not forced to relearn the editor on the same day a critical update arrives.

For extension authors, the deadline matters more. Anyone shipping a plugin that registers a product editor block, hooks into the experimental fills, or relies on the @woocommerce/product-editor npm package now has roughly six weeks to update. The package will not be there in 11.0. Extensions that depend on it will produce JavaScript errors in the admin and may break unrelated WooCommerce screens depending on how the import resolves. If you sell on the marketplace, treat this as a release-blocking issue for your July update.

The wider lesson is the one that keeps making WordPress the safe bet for enterprise commerce. WooCommerce is choosing maturity over novelty. The classic editor has had years of accumulated extension support, accessibility tuning, and muscle memory. The team is acknowledging that, consolidating effort, and not asking stores to absorb the cost of an unfinished experiment. It is the kind of decision you only make when you are confident the platform is around long enough that you can afford to say no to things.

What I would do (or not do) about it

This week, three things go on my list for every WooCommerce client we run.

First, I audit Settings. Go to WooCommerce > Settings > Advanced > Features and check whether the new product editor is enabled. If it is, I switch it off now, while we are still on 10.8. That gives the team several weeks of normal editing before 10.9 arrives. It also lets me check that any custom field, ACF group, or YITH/Iconic/etc. extension still presents itself the way the merchant expects in the classic screen. I do not want surprises in production on June 23.

Second, I grep the codebase. On every custom plugin and child theme in the project, I run a search for @woocommerce/product-editor, for product-block-editor-v1, and for any registration calls into the block-based editor. Anything that comes up gets a ticket with a July 14 deadline. That gives me two clean weeks of staging tests before 11.0 ships, which is the minimum I want for a major commerce release.

Third, I do not panic-rewrite anything for the classic editor that is already working. The classic product screen is not new code. Meta boxes, custom fields, Gutenberg-style sidebars on the post edit screen — all of that continues to function. If an extension was already shipping a classic UI alongside its block UI, you keep the classic one and drop the block half. If an extension only ever shipped block UI, that is the real work this month: rebuilding the merchant-facing surface as a meta box or a custom field group.

What I am not doing is waiting for clarification. The advisory, the changelog, and the two GitHub issues are aligned. The timeline is concrete. Anyone holding off because they expect a reversal is reading the room wrong.

Retirements like this one are why agencies still bet on WooCommerce for serious commerce work. The platform is willing to remove its own code when the experiment did not land. Five weeks of notice, no data migration, and a clear list of three strings to grep for is about as gentle as a deprecation gets.