WooCommerce 11.0 adds persistent product status counters so the Products screen does not recalculate every total on each request. The risk is not the cache itself. The risk is a product import, scheduled status change, extension, or direct database write that changes catalog state without clearing the counter used by administrators.
Use this for stores with large catalogs, scheduled products, bulk editors, ERP imports, marketplace sync, product duplication tools, multilingual copies, or custom statuses.
Quick answer
WooCommerce 11.0 Product Status Counter Cache Staleness Test should be handled with a narrow evidence-first workflow: capture baseline counts, run one change path, compare independent totals, then verify the result before making broader changes.
What to check first
- Record the visible All, Published, Draft, Pending, Private, Scheduled, and Trash totals before changing any product.
- Run one change at a time through the editor, bulk edit, CSV import, WP-CLI, scheduled publication, trash, restore, and the real catalog integration.
- Compare the screen counters with an independent database or WooCommerce data-store count after each change.
- Open the Products screen in a second administrator session to rule out a browser or request-local result.
- Test plugin activation, product-type changes, and a failed import rollback so counters recover from interrupted work.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Capture baseline counts | Record the visible All, Published, Draft, Pending, Private, Scheduled, and Trash totals before changing any product. | Every visible status counter matches an independent count after each product operation. |
| Run one change path | Run one change at a time through the editor, bulk edit, CSV import, WP-CLI, scheduled publication, trash, restore, and the real catalog integration. | Scheduled and background changes become visible without a manual cache purge. |
| Compare independent totals | Compare the screen counters with an independent database or WooCommerce data-store count after each change. | Trash and restore update both the old and new status totals once. |
| Test a second session | Open the Products screen in a second administrator session to rule out a browser or request-local result. | The integration owner confirms future writes use WooCommerce CRUD or an explicit supported invalidation path. |
Why this usually happens
- Persistent counters trade repeated computation for explicit invalidation when product status changes.
- Direct SQL updates can bypass WooCommerce CRUD hooks that normally clear dependent values.
- Bulk and scheduled operations may update many products across multiple requests or background jobs.
- Multilingual and marketplace extensions can create or change products outside the core admin workflow.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp post list --post_type=product --post_status=publish --format=count
wp post list --post_type=product --post_status=draft --format=count
wp post list --post_type=product --post_status=trash --format=count
# Compare these counts after each supported product-change path.
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Capture baseline counts
- Run one change path
- Compare independent totals
- Test a second session
- Repair bypassing integrations
Decision rule
Treat a one-count mismatch as a real failure. Do not manually clear the cache and call the test complete. Identify the write path that failed to invalidate the counter, then retest that exact path from a clean baseline.
What to tell the client or owner
Provide the status before and after, change method, product ID, expected counter, actual counter, cache backend, hook evidence, and the integration responsible for the write.
Production verification checklist
- Every visible status counter matches an independent count after each product operation.
- Scheduled and background changes become visible without a manual cache purge.
- Trash and restore update both the old and new status totals once.
- The integration owner confirms future writes use WooCommerce CRUD or an explicit supported invalidation path.
Mistakes to avoid
- Do not compare only the All counter.
- Do not use a manual cache purge as the permanent fix.
- Do not test only products edited through wp-admin.
- Do not let a direct SQL importer keep writing after a mismatch is proven.
Questions teams ask during testing
Can a stale object cache cause the same symptom?
Yes. Compare the WooCommerce counter source with Redis or another persistent cache and the database count. The write path still needs a reliable invalidation event.
Should counters update during a long import?
Document whether the integration commits in batches or at completion. The final state must always reconcile, and staff should know whether interim counts are expected to lag.
When HandL WP should help
HandL WP should help when administrators cannot trust catalog totals, imports use direct database writes, or persistent cache behavior differs across servers. We can trace the product write and invalidation path without disabling caching sitewide.
If this is active on a production site, repair WooCommerce product counter caching.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references