WooCommerce 11.1 adds GET /wc-analytics/activity-panel/counts to replace six requests used for activity panel counts. Consolidation can lower admin overhead, but extension panels, permission filters, cache layers, stale data, partial failures, and custom client code may still expect the old endpoints or count semantics.
Use this for stores and extensions that customize the WooCommerce admin activity panel, orders, reviews, stock alerts, inbox notes, or analytics request handling.
Quick answer
Record the six legacy responses, total request count, transferred bytes, TTFB, permissions, cache headers, and visible badges on a fixed database snapshot. Update to 11.1 and call /wc-analytics/activity-panel/counts with administrator, shop manager, restricted custom role, expired nonce, and unauthenticated sessions. Compare every returned count to its source query and visible panel. Confirm custom clients stop polling removed paths and that one failed count cannot expose another count or break the whole panel silently.
What to check first
- Capture legacy endpoint names, responses, timing, requests, roles, and visible badge totals before updating.
- Map each field in the consolidated response to its source query, capability, extension filter, and panel label.
- Test administrator, shop manager, custom role, expired nonce, logged-out, empty-store, and high-volume fixtures.
- Inspect REST cache, object cache, nonce, capability, error, and refresh behavior after state changes.
- Search extension JavaScript for direct calls to the six old requests and assumptions about independent loading states.
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 |
|---|
| Administrator | Known activity fixture | All authorized counts match |
| Shop manager | Same fixture | Only permitted counts |
| Expired nonce | Consolidated request | Safe authorization error |
| State change | Resolve one alert | Affected count refreshes |
Decision rule
Promote the endpoint when authorized counts match their source records, restricted roles reveal nothing extra, state changes invalidate correctly, custom clients stop legacy polling, and aggregate latency stays inside budget.
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.
- Freeze legacy request and count evidence on a known store state.
- Map consolidated fields to capabilities, filters, cache keys, and visible labels.
- Migrate custom clients to the documented aggregate route with resilient field handling.
- Align invalidation and permission checks, then retest state changes and failures.
- Monitor request volume, TTFB, error rate, count mismatch, and admin interaction timing.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Freeze legacy request and count evidence on a known store state. | Capture legacy endpoint names, responses, timing, requests, roles, and visible badge totals before updating. | One aggregate request replaces the intended legacy request set. |
| Map consolidated fields to capabilities, filters, cache keys, and visible labels. | Map each field in the consolidated response to its source query, capability, extension filter, and panel label. | Every returned and visible count matches the fixed database fixture. |
| Migrate custom clients to the documented aggregate route with resilient field handling. | Test administrator, shop manager, custom role, expired nonce, logged-out, empty-store, and high-volume fixtures. | Capabilities and nonce failures protect each count and the full response. |
| Align invalidation and permission checks, then retest state changes and failures. | Inspect REST cache, object cache, nonce, capability, error, and refresh behavior after state changes. | State changes refresh the affected field without stale aggregate cache. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
GET /wp-json/wc-analytics/activity-panel/counts
role,orders,reviews,stock,inbox,status,ttfb_ms
admin,4,2,3,1,200,180
shop_manager,4,2,3,1,200,184
custom_support,0,2,0,1,200,162
logged_out,-,-,-,-,401,74
Production verification checklist
- One aggregate request replaces the intended legacy request set.
- Every returned and visible count matches the fixed database fixture.
- Capabilities and nonce failures protect each count and the full response.
- State changes refresh the affected field without stale aggregate cache.
Why this usually happens
- A client keeps calling a legacy endpoint after core switches to the aggregate route.
- Object cache invalidation covers one count but not the consolidated response.
- A custom role has partial capabilities that were previously enforced per request.
- One slow source query now influences the latency of the combined response.
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, audit WooCommerce admin performance.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Move from endpoint evidence to release ownership
Use the WooCommerce 11.1 extension compatibility readiness matrix to assign fixtures, owners, evidence, rollback, and production decisions. For stale admin values after order changes, run the activity-count mutation and cache invalidation test.
Helpful references