Features
Activity (change record)
The Activity page keeps a record of every change Caching Out makes to your site, or is told to make: settings saves, Smart Config runs, Setup Wizard steps, settings imports, WP-CLI commands, .htaccess and advanced-cache.php writes, the WP_CACHE constant, cache purges, and per-page asset rules. Each entry shows who made the change, where it came from, what it changed, the value before and after, and whether it worked. Most settings changes can be undone from the same row with one click, after a confirmation screen.
It answers the question support gets asked most: "it worked yesterday, what broke it?"
What it covers, and what it does not
The record covers this plugin's own changes only. It does not see theme updates, other plugins' settings, host changes or FTP edits. If something changed and Activity shows nothing, the change was made somewhere else.
It is a diagnostic aid, not a security or compliance feature. It is not tamper-proof, it is not a WordPress activity log, and it records nothing about your visitors.
The record stays on your server. It is never sent as telemetry. The only way any of it leaves is inside a question you type to the AI Assistant, while "Let the AI Assistant see recent changes" is on (see Privacy).
Reading the page
Open Caching Out > Activity. Each row shows:
| Column | Meaning |
|---|---|
| When | How long ago; hover for the exact time |
| Who | The WordPress user, or System, Scheduled task, WP-CLI, Setup Wizard, Smart Config, Import or Activation |
| Source | The screen or command the change came from, for example admin.settings.file_optimization or cli |
| What | The kind of change: settings.change, purge, htaccess.write, htaccess.refused, autoconfig.apply, asset_rule.add and so on |
| Target | The setting (section.key), file, rule or page affected |
| Change | The value before and after; long values open with a details toggle |
| Result | OK, Refused or Error, with the reason |
| Revert | A button when the change can be undone, otherwise a dash (hover for why) |
Changes made in one go are grouped. A settings save that also rewrote .htaccess and purged the cache appears as one row with a +2 related toggle underneath, so one action reads as one change.
Filters: by type, by who, by period (last 24 hours, last 7 days, everything kept), and Problems only to show refused and failed changes. Fifty rows per page.
Reverting a change
Click Revert on the row. The confirmation screen shows the setting, the value that will be restored and the value stored right now, and lists the side effects (the page cache is purged when output settings change; browser-caching rules are rewritten for .htaccess settings). Confirm to apply.
A revert is written back as a normal settings save. Everything that usually follows a save happens too, and the revert itself appears in Activity as a revert.apply row plus the new settings.change row it produced. Reverting a revert is just reverting that row.
If the setting has changed again since the row was written, the confirmation screen says so. Reverting then replaces the current value, including any edits made in between.
What cannot be reverted, and why the row shows a dash:
- Purges, preload runs, activation, upgrade and re-run rows: nothing to restore.
- Drop-in and
WP_CACHEwrites: restored by deactivating and reactivating, not by a save. - Refused or failed changes: nothing happened, so there is nothing to undo.
.htaccesswrites: the block is generated from your settings, so revert the settings change in the same group instead.- Sensitive settings (API keys, the Cloudflare email address, licence fields): the value is stored as
[redacted], so it cannot be put back. - Values too large to store completely: a partial value is never written back.
The AI Assistant and reverts
With "Let the AI Assistant see recent changes" on (Cache tab), each question you ask carries a short summary of your recent changes alongside the filesystem and page-audit summaries. The assistant can then say which recent change most likely caused a symptom and offer to undo it.
It only ever proposes. A suggested revert appears as a button built from your own local record, never from the assistant's description of it. Clicking it opens the same confirmation screen as the Revert column, and nothing changes until you confirm there. Nothing is ever reverted unattended.
Export for support
Export for support on the Activity page (and on the Filesystem Check page) downloads the record as a JSON file that opens with a line naming your site and plugin version. Secrets stay [redacted] in the file exactly as they are in the table. Attach it to a support request so the conversation starts with what changed rather than "what did you change?"
Settings (Cache tab)
| Setting | Default | What it does |
|---|---|---|
| Record changes | On | Keeps the record. Turning it off stops new entries; existing ones stay until cleared or aged out |
| Changes to keep | 500 | The newest entries are always kept, whatever their age (50 to 5000) |
| Delete changes older than | 90 days | Only entries beyond the "changes to keep" count are removed by age (7 to 365) |
| Let the AI Assistant see recent changes | On | Sends the short summary with each chat question; inert if you never use the chat |
Recording is on by default because a record that starts after the incident is worthless: the first time anyone wants it is the one time it has no data. It costs nothing on a cached page (the drop-in never loads it) and writes only when an administrator changes something.
To stop every write regardless of the setting, add to wp-config.php:
define( 'CACHINGOUT_DISABLE_AUDIT', true );
The cache kill switch CACHINGOUT_DISABLE_CACHE deliberately does not disable the record. A bad-release investigation is exactly when you want it.
Clearing the log
Clear activity log removes every entry after a confirmation and leaves one marker entry saying the log was cleared, by whom and when, so a cleared log is distinguishable from an empty one. Export first if support may need it. The whole record is deleted when the plugin is deleted.
WP-CLI
# Newest changes first, as a table
wp cachingout audit list
# Only refused or failed changes, as JSON
wp cachingout audit list --problems --format=json
# Filter by type or user
wp cachingout audit list --type=settings.change --actor=1 --limit=100
# Export the last 7 days to a file
wp cachingout audit export --file=activity.json --since=7d
# Preview a revert (changes nothing), then apply it
wp cachingout audit revert 4213
wp cachingout audit revert 4213 --yes
revert without --yes prints the change it would make and exits without applying. Confirm-first holds on the command line too.
Where it is stored
In a table in your own database, {prefix}cachingout_audit, created on activation and on the first load after an update. On a host that refuses to create tables, the plugin falls back to keeping the most recent 100 entries in a WordPress option; the Activity page and the Filesystem Check page both say when that fallback is in use.
Troubleshooting
The Filesystem Check row "Change record (Activity)" shows Attention or Problem. Attention means the table could not be created and the 100-entry fallback is in use: deactivate and reactivate the plugin to retry, or ask your host whether CREATE TABLE is allowed. Problem means recent writes failed; open Activity to see what was recorded and reactivate the plugin to recreate the table.
A change I made is not listed. Check the period filter (the default view shows everything kept), then check whether recording is on (Cache tab). Changes made outside Caching Out are never listed.
A row shows htaccess.refused with cachingout_htaccess_foreign_marker. Another cache plugin's block with live directives is still in .htaccess; Caching Out will not write its own browser-caching rules until it is gone. See leftovers from a previous cache plugin.
The revert confirmation warns that the setting changed since. Someone (or Smart Config, or an import) edited the same setting after the row you are reverting. Compare the two values shown; reverting replaces the current one.
Revert reports that the value was rejected. The stored value no longer passes the settings sanitizer, usually because the setting's allowed range changed in an update. Set the value by hand on the relevant tab.