WooCommerce 11.1 stops exposing internal @woocommerce/entities utilities through window.wc.wcEntities. Extensions that read those utilities directly can fail only on affected admin routes, delayed chunks, minified production bundles, or cache combinations. A global existence check can also hide the problem when another extension happens to recreate the same property.
Use this for WooCommerce extension authors and site teams with custom admin JavaScript, product selectors, entity stores, reports, onboarding, or bundled code that references wcEntities.
Quick answer
Search source, built bundles, source maps, inline scripts, and browser globals for window.wc.wcEntities, wc.wcEntities, and deep internal entity utilities. Map every reference to the user journey and documented replacement. Build with explicit supported package imports or local code that does not depend on an internal global. Test cold and warm loads, chunk failure, script concatenation, admin route navigation, another extension absent, and production minification. Do not restore the removed global as a compatibility shim unless WooCommerce documents that path.
What to check first
- Search unbuilt source, distribution bundles, source maps, inline templates, and runtime global reads.
- Identify the exact utility, call shape, route, user role, package version, and supported replacement for each reference.
- Test direct route load and client-side navigation with all unrelated extensions disabled.
- Build production minified assets and verify dependency order, chunk loading, console errors, and tree shaking.
- Clear asset, opcode, object, CDN, service-worker, and browser caches before the final parity run.
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 |
|---|
| Cold route | Open affected admin URL directly | No missing global |
| Client navigation | Move between Woo screens | Control mounts once |
| Minimal plugins | Only Woo and extension | No borrowed shim |
| Production bundle | Minified and cached | Supported import works |
Decision rule
Approve the extension when no source or built asset references the removed global, all affected routes pass without another extension present, and the replacement uses a documented dependency contract.
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 every source and compiled reference with its affected route.
- Replace internal global access with a documented public package, data store, or owned adapter.
- Declare explicit supported dependencies in the build and WordPress enqueue graph.
- Test minimal-plugin, cold-load, navigation, minified, and cache states.
- Remove temporary diagnostics, publish the compatibility range, and keep a paired rollback.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Inventory every source and compiled reference with its affected route. | Search unbuilt source, distribution bundles, source maps, inline templates, and runtime global reads. | Source, bundles, source maps, and runtime logs contain no wcEntities global access. |
| Replace internal global access with a documented public package, data store, or owned adapter. | Identify the exact utility, call shape, route, user role, package version, and supported replacement for each reference. | Cold loads and client-side navigation pass on every affected admin route. |
| Declare explicit supported dependencies in the build and WordPress enqueue graph. | Test direct route load and client-side navigation with all unrelated extensions disabled. | The extension works with unrelated plugins disabled and production minification enabled. |
| Test minimal-plugin, cold-load, navigation, minified, and cache states. | Build production minified assets and verify dependency order, chunk loading, console errors, and tree shaking. | Declared dependencies, compatibility range, rollback, and owner are current. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
# Search source and built output
rg "window\.wc\.wcEntities|wc\.wcEntities|@woocommerce/entities" src build dist
route,utility,replacement,cold,warm
/products,internalSelector,supported data store,pass,pass
/reports,formatEntity,local adapter,pass,pass
Production verification checklist
- Source, bundles, source maps, and runtime logs contain no wcEntities global access.
- Cold loads and client-side navigation pass on every affected admin route.
- The extension works with unrelated plugins disabled and production minification enabled.
- Declared dependencies, compatibility range, rollback, and owner are current.
Why this usually happens
- Development mode places more packages on window than the production route.
- Another extension accidentally supplies the global and masks the dependency.
- A dynamic chunk reads the property after the route changed.
- A bundler externalizes an internal package without a supported WordPress handle.
Field notes
- Use synthetic IDs and examples that can be traced from the first request or interaction to the final record.
- Keep a before and after result for every changed setting, package, selector, route, or deployed version.
- Separate user-visible success from internal success so a green interface cannot hide a failed request or inaccessible control.
- Review the evidence again after caches, queues, browser history, and scheduled work have had time to settle.
Mistakes to avoid
- Changing production before recording exact versions, UTC timestamps, settings, stable fixture IDs, and a reproducible baseline.
- Treating one successful screen as proof that keyboard access, APIs, caches, jobs, reports, analytics, and downstream records agree.
- Testing only an administrator session instead of the devices, roles, networks, consent states, and failure branches customers use.
- Closing the work without a named owner, rollback point, observation window, and contextual incoming link from an established guide.
What to tell the client or owner
Give the site owner the affected versions, exact synthetic fixture, UTC timeline, before and after evidence, cause class, decision, rollback point, unresolved risks, and next review date. State which measurements prove success and which observation window remains open.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only checks and one narrow synthetic fixture that cannot charge a card, send real customer email, expose personal data, or change inventory. Run upgrades, package changes, cache changes, and destructive repairs on staging first.
What evidence should the test report keep?
Keep exact versions, UTC timestamps, stable synthetic IDs, expected and actual results, screenshots or response excerpts, the decision owner, rollback point, and final verification. Redact credentials, tokens, customer data, private addresses, and infrastructure details.
How long should the observation window stay open?
Keep it open long enough to include at least one cache cycle, scheduled job cycle, and representative traffic period. For release changes, include both logged-in and logged-out use plus the first real operational handoff.
When is the task complete?
Complete it when the primary user path passes, downstream records reconcile, failure branches are understood, monitoring is active, and an established owner page links to this guide in context.
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, migrate a WooCommerce extension.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Search lazy chunks and source maps for removed wcEntities calls
After source migration, use the WooCommerce 11.1 wcEntities dynamic chunk audit to inspect compiled bundles, source maps, cold routes, client navigation, runtime manifests, service workers, and CDN versions.
Helpful references