WooCommerce 11 removes the beta Product Editor, its feature flag, editor-specific routes, related extension points, and the @woocommerce/product-editor package. Product data remains, but extension code that imports the package or registers beta-only blocks, slots, fills, or routes can fail during build, activation, admin load, or product editing. The audit needs both static code evidence and a complete classic-editor workflow test.
Use this for custom WooCommerce extensions, agency plugins, private integrations, and stores that enabled the beta Product Editor. Store owners should confirm they are back on the classic editor. Developers should test source, built assets, packaged zip, upgrade, and clean install paths.
Quick answer
Search source, lockfiles, built JavaScript, PHP, tests, feature flags, routes, and documentation for the retired package and beta editor contracts. Classify each match as remove, replace with supported product data APIs, or migrate to a classic-editor hook. Build the distributable package without the dependency, then test product create, edit, variation, inventory, pricing, media, metadata, save, REST, and order use cases on WooCommerce 11.
What to check first
- Search for @woocommerce/product-editor, product-block-editor-v1, beta feature flags, experimental APIs, editor routes, blocks, slots, fills, and package handles.
- Inspect compiled bundles and dependency extraction output because a removed import may survive outside the readable source tree.
- Map each editor integration to the business requirement it served and decide whether it should be removed or rebuilt with a supported classic-editor or product-data contract.
- Test simple, variable, downloadable, virtual, sale-priced, backordered, and extension-specific products through create, edit, duplicate, import, REST update, and checkout.
- Run upgrade and clean-install tests with the packaged extension while logging JavaScript errors, PHP notices, missing handles, failed builds, and lost product fields.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Inventory every retired editor contract | Search for @woocommerce/product-editor, product-block-editor-v1, beta feature flags, experimental APIs, editor routes, blocks, slots, fills, and package handles. | Static and built-asset searches contain no unexplained retired imports. |
| Map matches to business requirements | Inspect compiled bundles and dependency extraction output because a removed import may survive outside the readable source tree. | The extension activates without missing script handles or admin console errors. |
| Remove or migrate beta-only integrations | Map each editor integration to the business requirement it served and decide whether it should be removed or rebuilt with a supported classic-editor or product-data contract. | All supported product types preserve extension fields and validation. |
| Build and inspect the customer package | Test simple, variable, downloadable, virtual, sale-priced, backordered, and extension-specific products through create, edit, duplicate, import, REST update, and checkout. | Upgrade and clean-install packages pass the same workflow matrix. |
Why this usually happens
- An experimental package can become a transitive dependency hidden in a shared bundle.
- A feature flag may hide code during normal store testing while the import remains in the package.
- Product data survives the editor retirement, so data checks alone can miss a broken admin workflow.
- A classic-editor replacement may save a field but omit validation, variation handling, REST exposure, or capability checks.
- Development builds can resolve workspace packages that are absent from the customer zip.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
rg -n "@woocommerce/product-editor|product-block-editor-v1|__experimental|product editor" src build tests package.json composer.json
npm ls @woocommerce/product-editor || true
wp plugin activate my-extension
wp option get woocommerce_feature_product_block_editor_enabled
# Test the packaged zip on WooCommerce 11, not only the monorepo workspace.
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Inventory every retired editor contract
- Map matches to business requirements
- Remove or migrate beta-only integrations
- Build and inspect the customer package
- Test product workflows on upgrade and clean installs
Decision rule
Pass when the packaged extension has no runtime or build dependency on removed Product Editor code and every required product workflow works in the supported editor and data APIs. Do not replace an experimental contract with another undocumented internal contract just to silence the first error.
What to tell the client or owner
Give the site owner the affected version, exact workflow, observed result, business impact, evidence location, temporary control, named owner, and next review time. Remove credentials and personal data from shared screenshots and logs.
Production verification checklist
- Static and built-asset searches contain no unexplained retired imports.
- The extension activates without missing script handles or admin console errors.
- All supported product types preserve extension fields and validation.
- Upgrade and clean-install packages pass the same workflow matrix.
Mistakes to avoid
- Do not assume products disappearing is the expected failure.
- Do not search source while ignoring built bundles and lockfiles.
- Do not keep a dead feature flag around a removed import.
- Do not test only a simple product with no extension metadata.
Questions teams ask during testing
Will WooCommerce 11 delete product data?
No. The retirement removes the experimental editing surface and related code, not the product data layer.
What should replace @woocommerce/product-editor?
That depends on the requirement. Use supported product data APIs and established classic-editor extension points where the UI is still needed.
When HandL WP should help
Bring in HandL WP when this affects a production site, paid lead flow, checkout, email delivery, or a managed fleet. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, the external service, logs, and the user journey.
If this is active on a production site, audit a WooCommerce 11 extension.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references