A changed report total after a WooCommerce update does not prove that orders, users or reviews were deleted. Check whether the report still executes the customization that previously restricted its results.
Scope the affected endpoint
WooCommerce 11.2 changes query-hook behavior for customer and review totals. Several general user/comment query hooks no longer run there, and comment-clause handling is grouped differently. The developer advisories identify this compatibility change.
Record the exact report, request URL, date range, filters and account role. Customer counts, review totals and sales revenue are not interchangeable. For revenue and refunds, use the separate sales reconciliation workflow.
Establish the expected subset
Create a tiny staging fixture whose membership you can explain without relying on the report. For reviews, record the synthetic product IDs, review IDs, ratings and approval states. For customers, record the test IDs and why each should be included or excluded by your customization.
Write down the expected count before loading the report. That prevents changing the expectation to match whichever number the new endpoint returns. Do not use customer names or email addresses in diagnostic screenshots.
Scope: Endpoint and filters unchanged. Data: Use synthetic customer/review IDs. Roles: Preserve report access controls. History: Label changed count definitions. Explanatory checklist, not a customer test result.
Trace a callback without changing data
Instrument the relevant callback on staging with a private, minimal diagnostic marker. Record whether it runs for the specific report request and whether its scope matches what you intended. Avoid logging full SQL containing personal data or credentials.
Compare the same request on your baseline and updated environment. Keep the fixture and filter settings identical. If the old callback no longer runs, repeatedly clearing analytics caches is unlikely to restore its effect.
| Observation |
Next investigation |
| Callback no longer executes |
Find the supported extension point for that endpoint |
| Callback executes but count differs |
Examine grouped-query assumptions and filter scope |
| Raw response is correct, screen differs |
Inspect frontend state and report caching |
| Fixture membership changed |
Resolve data changes before judging the callback |
Migrate the behavior, not a hook name
Ask the extension maintainer to reproduce the intended reporting restriction using the installed WooCommerce version's supported interface. Do not substitute an arbitrary global filter that changes unrelated user or comment queries across the site.
Preserve the report's access controls. A change intended to hide test records must not expose customer details to a lower-privilege user. Test both an authorized report viewer and an account that should be denied.
If no suitable extension point exists, document the limitation and use a clearly scoped export or maintained reporting integration while seeking a supported solution. Do not edit genuine customer records just to make a dashboard match its former total.
Acceptance record
Keep the fixture IDs, expected membership, old/new responses, callback observations and final role checks. Distinguish a compatible new result from historical reports generated under a different definition. HandL WP can trace the report customization when the endpoint and the plugin disagree about which records belong in the total.
References reviewed October 16, 2026. Examples are explanatory, not customer test results.