WooCommerce 11.1 stops exposing internal @woocommerce/entities utilities through window.wc.wcEntities. A source-code search may pass while minified vendor bundles, old source maps, dynamic imports, cached chunks, admin-only routes, or a dependency package still reads the removed global. The error often appears only after direct navigation, a cold cache, or a specific extension panel loads.
Use this for WooCommerce extensions with React admin screens, code splitting, dynamic imports, externalized WordPress packages, long-lived CDN caches, service workers, or multiple build pipelines.
Quick answer
Search source, lockfiles, built JavaScript, source maps, and deployed chunks for wcEntities and @woocommerce/entities. Build a route manifest, then open each route directly with a cold browser and navigate to it from another screen. Record requested chunk names, versions, console stacks, network cache status, and loaded dependency handles. Replace internal globals with supported package imports or public APIs, rebuild every entry, version asset URLs, purge caches, and prove the old string is absent from production artifacts.
What to check first
- Search application source, dependencies, lockfiles, generated bundles, minified chunks, source maps, release archives, and deployed assets.
- Map every admin and editor route to its initial and lazy JavaScript chunks, including permission-dependent panels.
- Test direct cold entry, warm reload, client navigation, back and forward, cache HIT, service worker, and a second browser profile.
- Capture console stacks, network initiators, chunk hashes, package versions, dependency handles, and source-map locations for each failure.
- Verify the deployed release contains no stale chunk URL referenced by HTML, runtime manifests, preload tags, CDN objects, or service workers.
Why this usually happens
- A transitive dependency reads the internal global in a lazy path.
- The main bundle was rebuilt but an old dynamic chunk remained in the release or CDN.
- A source map points to the original package even though the visible stack is minified.
- A service worker or cached HTML requests chunks from two releases.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
rg -n "wcEntities|@woocommerce/entities" src node_modules dist build '*.map'
find dist -type f -name '*.js' -o -name '*.map' | sort
# Record direct route, requested chunks, cache status, and release hash.
release_id=2026-08-23-wave65
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Build a complete route-to-chunk and dependency inventory. | Search application source, dependencies, lockfiles, generated bundles, minified chunks, source maps, release archives, and deployed assets. | Source, bundles, maps, archives, and deployed chunks are free of wcEntities references. |
| Replace removed internal globals with supported imports or public data APIs. | Map every admin and editor route to its initial and lazy JavaScript chunks, including permission-dependent panels. | Every direct and client-navigated route loads without a missing-global error. |
| Rebuild every entry and fail CI if compiled artifacts contain wcEntities. | Test direct cold entry, warm reload, client navigation, back and forward, cache HIT, service worker, and a second browser profile. | Runtime manifests, preload links, service workers, and CDN objects share one release ID. |
| Version runtime manifests and asset URLs, then purge HTML, CDN, and service-worker caches in order. | Capture console stacks, network initiators, chunk hashes, package versions, dependency handles, and source-map locations for each failure. | Rollback restores a complete compatible asset set rather than mixed chunks. |
Decision rule
Promote the extension when source and production artifacts contain no removed global reference, every cold lazy route passes, and asset versioning prevents HTML and chunks from different releases from mixing.
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 direct route | Analytics extension panel | No removed global access |
| Client navigation | Orders to settings | Lazy chunks load cleanly |
| Old HTML cache | Prior runtime manifest | Version mismatch is blocked |
| Production maps | Search compiled artifacts | No wcEntities reference |
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.
- Build a complete route-to-chunk and dependency inventory.
- Replace removed internal globals with supported imports or public data APIs.
- Rebuild every entry and fail CI if compiled artifacts contain wcEntities.
- Version runtime manifests and asset URLs, then purge HTML, CDN, and service-worker caches in order.
- Retest direct and navigated cold routes across roles before promotion.
Production verification checklist
- Source, bundles, maps, archives, and deployed chunks are free of wcEntities references.
- Every direct and client-navigated route loads without a missing-global error.
- Runtime manifests, preload links, service workers, and CDN objects share one release ID.
- Rollback restores a complete compatible asset set rather than mixed chunks.
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.
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, locales, and failure branches customers use.
- Closing the work without a named owner, rollback point, observation window, and contextual incoming link from an established guide.
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 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 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, repair a WooCommerce extension build.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references