Trace the exact cached value to its key, group and invalidation owner, then verify a supported write updates the next relevant read without a global flush.
Old object-cache data needs a key-and-invalidation investigation. Confirm that the authoritative record changed, identify which cached value the application reads and trace how the normal write path invalidates it. A global flush can temporarily hide the defect while leaving the same stale result to return later.
In a fictional WordPress workshop directory, an editor closes registration for a session. Its detail page updates, but a custom “Open this week” summary still lists it. The summary may be a separately cached query result. Clearing the page cache cannot explain why newly generated HTML keeps including the old session.
Locate the old value before naming the cache
Record the record identifier, expected state, affected route and access context. Compare the saved source, application retrieval and final response using authorized tooling. Keep private values out of the diagnostic record.
If the source record still says open, investigate the write. If the application retrieves the correct closed state but the browser sees old HTML, investigate response caching. Only narrow the diagnosis to an object-cache result when evidence places the mismatch there.
The cache-layer guide covers the broader response journey. This guide addresses application values reused while generating a response, rather than a complete HTML page reused after generation.
Identify the persistent implementation
WordPress’s object-cache reference explains that core caching is normally limited to a request, while a persistent implementation can retain values across requests. Developers should use the wp_cache functions rather than the class directly. Confirm the actual installed backend and its supported behaviour.
Ask who owns its integration and which sites share the service. A cache service being present does not prove that this installation uses it. Conversely, a plugin dashboard may not display every relevant drop-in or host-managed integration.
For the directory, record the effective backend, site scope and whether the custom summary uses it. Do not disable persistence across production merely to see whether the symptom disappears. A controlled comparison on a protected copy can establish the relationship more safely.
Follow the key, group and result shape
Ask the developer to trace the retrieval and storage calls for the affected summary. Record the key, group, expiry if any, and inputs determining the result. Do not dump the entire cache: entries can include private records or integration values.
The summary key may depend on week, category, language or audience. If a necessary input is missing, two requests can incorrectly share one value. If the write invalidates one spelling but the read uses another, a nominal cleanup will miss the actual entry.
| Boundary | Question | Evidence |
|---|---|---|
| Authoritative record | Did registration really close? | Supported record readback |
| Cached summary | Which inputs identify this result? | Key, group and scoped result shape |
| Update path | Which operation marks it stale? | Writer and invalidation relationship |
| Generated response | Does a fresh render use the new result? | HTML or data response from that render |
Distinguish core cleanup from custom dependencies
The clean_post_cache() reference shows core post-related cleanup and change tracking, with an invalidation-suspension condition. This does not establish that a custom plugin’s independently named summary is invalidated. Inspect the component that derives and stores that summary.
In the fictional directory, a native post update can refresh the detail data while leaving a custom aggregate unchanged. The aggregate owner needs to define which changes invalidate it: status, date, taxonomy and perhaps related availability records.
Direct database writes deserve particular attention because they can bypass application update paths. Prefer the owning component’s supported API and lifecycle. Do not propose a universal cleanup function without checking which records and derived values the real writer affects.
Use targeted removal as a diagnostic, then repair ownership
WordPress documents wp_cache_delete() as removing contents matching a key and group. On an authorized test copy, targeted removal of the known summary can help confirm that regeneration reads current source data. It is a change, not a read-only observation.
If the regenerated summary becomes correct, retain the key evidence and investigate why the normal write did not invalidate it. If it remains wrong, inspect query logic and source selection instead of flushing more broadly.
Do not turn manual removal into a recurring operational ritual. A durable correction links the right mutation to the right derived result and preserves an appropriate regeneration path when the entry is absent.
Review isolation and concurrency
The private-response cache guide concerns HTTP responses. Object caches need their own audience and identity review too. A key that omits required user or permission context can produce a correctness or privacy defect, not merely stale public content.
Use synthetic accounts to inspect different allowed views where the result is personalized. Do not include secrets in a key or public debug output. Establish which dimensions the application intentionally shares.
Also test a write during regeneration. A slow query that started before an edit can finish afterwards and store an outdated result. The developer may need a version or ordering strategy suited to the application; repeatedly deleting the same key is not a universal concurrency solution.
Include deletion and relationship changes in the dependency review. Closing a session is one mutation; deleting it, moving it to another category or changing a related venue can affect different summaries. List those supported writers so the repair does not work only for the one edit used in the first reproduction.
Verify cold, warm and changed reads
- Obtain the correct result with the known cache entry absent on a test copy.
- Repeat a read and confirm the warm result remains correct.
- Change the source through the normal supported writer.
- Read again without a global flush and inspect the derived result.
- Repeat relevant category, language and account contexts.
- Exercise a concurrent regeneration case if the workload permits it.
- Check errors and source failure without inventing a successful empty result.
Measure performance separately using the query diagnosis workflow. A correct invalidation path can increase a necessary regeneration while improving correctness; that is different from claiming a measured speed improvement.
Accept the repair when a legitimate write leads to the correct next relevant read and unrelated results remain intact. Keep the cache dependency map small and explicit so future writers know which values their changes affect.
Sources and verification
Editorial review 2026-10-17. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- WordPress: WP_Object_CacheChecked Object caching reduces repeated expensive work; core cache is request-local unless a persistent implementation is installed; use wp_cache functions.
Limits: Backend implementation and supported operations vary; the class does not identify a specific site's cache keys. - WordPress: wp_cache_delete()Checked Targeted removal matches a key and group.
Limits: Deleting one entry does not automatically discover derived values or correct their invalidation owner. - WordPress: clean_post_cache()Checked Core post cleanup removes associated cached data and updates post-cache change tracking; invalidation can be suspended.
Limits: Does not promise to invalidate every custom plugin query cache or external page cache.