WooCommerce 11.1 includes an experimental feature that replaces many per-block editor scripts and styles with shared bundles. Frontend assets are unchanged, but an extension may enqueue against an older handle, localize data onto it, dequeue it, inspect its registration state, or assume a particular execution order in the product or site editor.
Use this for WooCommerce extension developers, custom blocks, agency plugins, product editor integrations, admin performance work, and stores considering the experimental unified editor assets feature.
Quick answer
Keep the feature disabled while you inventory every extension callback that registers, enqueues, localizes, dequeues, or declares dependencies on WooCommerce editor handles. Capture a baseline network waterfall and registered-handle list. Enable the feature on staging and repeat the product editor, Site Editor, template editing, reusable pattern, block insertion, settings, save, refresh, and error-recovery flows. Compare request count, bytes, dependency order, localized objects, console errors, visual output, saved markup, and frontend output.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Feature off | Legacy handles | Baseline editor |
| Feature on | No custom extension | Shared bundles pass |
| Legacy dependency | Custom block | Dependency mapped |
| Localized data | Old handle target | Object available once |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Inventory handle dependencies | Record WooCommerce, WordPress, Gutenberg, theme, extension versions, feature state, editor route, registered handles, enqueued handles, dependencies, localized objects, and network timing. | Editor routes load required scripts and styles once with no missing dependency or console errors. |
| Capture the feature-off baseline | Search custom PHP and JavaScript for wp_register_script, wp_enqueue_script, wp_localize_script, wp_add_inline_script, wp_dequeue_script, dependency arrays, and handle-name comparisons. | Extension controls receive their localized data and save the expected product or block state. |
| Enable only on staging | Test product editor, post editor with Woo blocks, Site Editor templates, synced patterns, block inserter, sidebar controls, autosave, revision restore, failed save, and direct editor reload. | Frontend markup and assets remain unchanged except for intended content edits. |
| Update extension integration points | Compare JavaScript and CSS request count, transferred bytes, evaluation time, dependency order, global data, source maps, console output, editor visuals, stored block markup, and frontend page. | Turning the experiment off restores the baseline without cache or registration leftovers. |
What to check first
- Record WooCommerce, WordPress, Gutenberg, theme, extension versions, feature state, editor route, registered handles, enqueued handles, dependencies, localized objects, and network timing.
- Search custom PHP and JavaScript for wp_register_script, wp_enqueue_script, wp_localize_script, wp_add_inline_script, wp_dequeue_script, dependency arrays, and handle-name comparisons.
- Test product editor, post editor with Woo blocks, Site Editor templates, synced patterns, block inserter, sidebar controls, autosave, revision restore, failed save, and direct editor reload.
- Compare JavaScript and CSS request count, transferred bytes, evaluation time, dependency order, global data, source maps, console output, editor visuals, stored block markup, and frontend page.
- Disable the experiment and confirm the old per-block path returns cleanly without stale caches, duplicate registrations, missing localized data, or modified content.
Field notes
- Write the pass condition before changing anything. A repeatable synthetic fixture makes the before and after comparison useful.
- Keep exact versions and UTC timestamps because scheduled jobs, caches, retries, and background processing can change the evidence.
- Check the public experience and the stored server-side result. Admin previews and isolated API calls do not prove the whole workflow.
- Repeat the test after the relevant cache, queue, scheduled action, webhook, and observation window has finished.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp option get woocommerce_feature_unified_editor_assets_enabled
wp eval 'global $wp_scripts; do_action( "admin_enqueue_scripts" ); print_r( array_keys( $wp_scripts->registered ) );'
# Compare exact editor routes before and after the experiment.
Why this usually happens
- An extension treats a script handle as a public API even though it was an implementation detail.
- Localized data attaches to a handle that is no longer enqueued in the experimental path.
- A dequeue optimization removes a shared bundle used by several blocks.
- A cache serves an old dependency map with new plugin files.
Decision rule
Enable the feature only when every supported editor flow retains required dependencies and localized data, saves identical intended content, improves or preserves performance, and can return cleanly to the legacy asset path.
Production verification checklist
- Editor routes load required scripts and styles once with no missing dependency or console errors.
- Extension controls receive their localized data and save the expected product or block state.
- Frontend markup and assets remain unchanged except for intended content edits.
- Turning the experiment off restores the baseline without cache or registration leftovers.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Inventory handle dependencies
- Capture the feature-off baseline
- Enable only on staging
- Update extension integration points
- Retest editor and frontend output
Mistakes to avoid
- Changing production before recording exact versions, UTC time, the affected fixture, current behavior, and a tested rollback point.
- Accepting one successful admin screen while the public page, stored record, API response, accessibility tree, queue, email, or downstream system remains unchecked.
- Testing only as an administrator instead of the role, browser, device, locale, network state, and failure path that a real customer reaches.
- Leaving broad credentials, debug logs, temporary filters, synthetic records, or recovery code active after verification.
Questions teams ask during testing
Should I test this on production?
Use production for read-only evidence first. Reproduce the change on staging with a current data shape, theme, extensions, cache, and browser mix. If a production canary is necessary, make it reversible, identifiable, monitored, and unable to charge a customer or expose personal data.
How do I rule out a cache artifact?
Record the origin response, purge only affected paths, and repeat in private and normal sessions. Compare stored data and server logs with the visible page. A cache hit is useful evidence only when you know which version it contains.
What belongs in the evidence packet?
Keep UTC time, exact versions, fixture ID, role, browser, expected result, actual result, relevant response or log lines, change made, rollback point, owner, and final verification. Redact passwords, tokens, personal data, and private URLs.
When is the test complete?
Close it when the main path and important failure branches pass, records reconcile across systems, accessibility and mobile checks are complete, temporary changes are removed, and monitoring covers the next update or business cycle.
What to tell the client or owner
Give the owner a short packet with the affected workflow, exact versions, UTC test time, fixture ID, expected result, actual result, key evidence, change made, rollback point, unresolved risk, owner, and next review date. Remove credentials and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP test a WooCommerce extension.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references