Troubleshooting tab (walk-back)

It is the guided front end of the Activity record: every change it lists comes from there, and every change it makes is written there too.

What it is, and what it is not

• It ranks suspects; it does not name "the cause". A suspect is a recorded change that often produces this kind of problem, made in the window you chose. The ranking is a hint to look at first, not a verdict.
• It only sees recorded changes: Caching Out's own settings and actions, plus plugin, theme and WordPress core updates, activations, deletions and theme switches since 1.26.0. A change made in another plugin's settings, in your theme files or on the server is not in the record and cannot be a suspect.
• It only applies fixes the plugin can perform and undo: reverting a Caching Out setting, excluding a script or stylesheet, turning a feature off for one page, applying a known compatibility rule, or purging. It never rolls back someone else's code. For a third-party update with no known rule it says so and gives you a copyable summary for that plugin's support.
• It works without the AI assistant and without a network connection. When the diagnostic service is reachable and licensed it may add reasons to a suspect; it never removes one.
• It decides nothing about caching itself. "Check the page" asks the same rule engine the cache uses and shows the answer.

The six steps

Each step is a normal page: you can use the browser's back button, bookmark a step, or come back a day later through Earlier problems. Nothing changes until you press a button that says so.

1. What's wrong?

Pick the closest description:

Which page? is optional but worth filling in: with a page, step 4 can check how the cache treats it and read its Page Audit findings, and step 5 can offer "turn this off for this page only". Only a page on this site is accepted.

2. When did it last work?

Pick a preset (earlier today, yesterday, the last 3 days, week or month) or a date and time in your site's timezone. Only changes after that moment are considered. When in doubt, pick an earlier time: a wide window adds suspects to the bottom of the list, a narrow one can miss the real one.

The page shows when your change log starts. The record is pruned by the Activity retention setting; a time older than the oldest entry is moved up to it and the page says so.

3. What changed since then

Every recorded change in the window, grouped the way the Activity page groups them (a settings save and the purge it triggered are one entry). Under Likely causes, most likely first each suspect shows what changed in plain words, when and by whom, and Why this is suspected: the parts of its score written out, for example "Changed after the page last worked; JavaScript settings commonly break buttons and forms; a Page Audit finding on this page points at this setting".

The top three are expanded, the rest collapsed. Changes that are never a suspect for this problem sit under Other changes in this window. Preload runs, filesystem re-checks and the notes of other troubleshooting cases are hidden behind an N routine events hidden toggle; they are all still on the Activity page.

A suspect you already tried a fix for is marked Tried – did not help.

4. Check the page now

Only with a page from step 1. Three things, all read-only:

1. The cache decision for an anonymous visit of that page: "Visitors get a cached copy of this page", or "Visitors do not get a cached copy" with the rule that decided, in words, and what to do about it. This is the same check as the Cache tab's page check and the X-CachingOut-Cache header.
2. Page Audit findings for the page. A finding that was not there the last time the page was audited before your window is marked New since it last worked.
3. Whether a cached copy is on disk, and how old it is.

5. Try a fix

One fix at a time. Each suspect lists the fixes the plugin can perform for it; open one to read exactly what would change (the setting, its value now and after the fix, taken from your site, never from model text), what else happens (a purge, an .htaccess rewrite), and then Apply.

Before the first fix of a case, a snapshot of your settings is saved (without API keys and licence data). Every fix after that can be undone one at a time, or all at once by restoring the snapshot. A setting that changed between the moment you read the panel and the moment you pressed Apply is not overwritten: the panel reloads with the current value and nothing is applied.

Preview first is shown but not yet available; it arrives in a later version.

6. Is it fixed?

Open the page in a new tab and look. The cache check from step 4 is re-run here.

• Yes, it's fixed closes the case as solved and shows a summary card (problem, the suspected change, the fix, who and when) with a Copy summary field for a client or a support ticket.
• No – undo this fix and try the next reverts that fix's own changes, marks the suspect as tried, and returns to step 3.
• Undo everything from this case restores the snapshot saved before the first fix. A setting you saved after the snapshot and that no fix touched is kept.
• Ask the assistant opens the AI Assistant with the case attached (its symptom, window, page path, suspects and tried fixes; see Privacy for what is sent). Export for support downloads the Activity record for the case's window.
• Close without a fix keeps the case under Earlier problems with the status Closed.

A case left open for seven days closes itself.

The urgent path: private content shown to visitors

If someone saw another person's account, cart or admin bar, choosing that option in step 1 skips the walk-back. The page shows, in order:

1. Purge every cache layer now: one button that empties the page cache and asks every connected edge (Cloudflare, Varnish, Sucuri) to drop its copies.
2. Switch caching off completely: the line to add to wp-config.php (define( 'CACHINGOUT_DISABLE_CACHE', true );). The page shows it and never writes it for you; it stops every cache read and write until you remove it. See the emergency switch.
3. How the cache treats the page, if you gave one: the rule that applies to an anonymous visit.
4. Export for support: the last seven days of changes, and the support address.

The case is recorded (status Urgent) so the event is on the timeline for later.

What can be undone

Every apply and undo is an Activity row (case.fix, case.undo), so the Activity page alone tells the whole story. Reverting from the Activity page works on the same rows.

Where things are stored

Cases live in one option (cachingout_walkback_cases, the last 20 per site). The settings snapshot of a case is a second option that is deleted with the case. Nothing is sent anywhere unless you press Ask the assistant; the WP-CLI equivalents are wp cachingout walkback changes|suspects|check (see WP-CLI).

Performance results vary depending on hosting, theme, plugins and traffic. The walk-back narrows down what changed; it does not guarantee that undoing a change restores a page.