WordPress Cache Plugin MCP that measures before it keeps a change.

Shared keys, native settings and presets: three ways to change a cache plugin

Every cache plugin here answers the same module, but each exposes a different share of its own settings to it. The table above shows the split. Mapped keys are the shared vocabulary, such as page cache on, CSS minify or JavaScript defer, that cache-set-settings writes on any plugin that supports them. Native fields are the plugin's own option names, reachable through cache-set-native for everything the shared model does not cover; LiteSpeed's guest mode, ESI and per-asset exclusions are examples. A plugin with no native fields declared, such as W3 Total Cache, is limited to the shared keys.

cache-set-native refuses any key it cannot read back first, so a key renamed between plugin versions is rejected instead of creating an option the plugin ignores. Read with cache-get-settings and include_native before writing.

When a preset is the right tool, and when it is not

cache-list-presets shows the conservative, balanced and aggressive configurations and, more usefully, which keys would actually change on this site. cache-apply-preset writes them as one ledger entry that rollback-change undoes in full; the aggressive preset needs confirm because it includes the gated keys. A preset suits a site where the cache plugin was installed and never configured. On a site you are tuning against measurements, set one key at a time instead, because a preset that makes things slower will not tell you which of its settings did it.

Actions that are not settings, and the ones you cannot undo

Crawling, preloading and database clean-up are listed by cache-list-actions and run with cache-run-action. Each entry says whether the action blocks, whether it is destructive and whether its entry point resolves on this install, and an unavailable one is refused rather than reported as done. Database clean-up deletes rows such as old revisions; it needs confirm and the change ledger cannot bring them back, because the ledger restores settings, not deleted content. Take a backup before any destructive action, and re-measure later after a non-blocking one, since it only queued the work.

One page cache per site

Stacked caching is normal: a page cache, an asset optimiser, an object cache and a CDN each do a different job. Two page caches doing the same job is not. Run cache-check-setup on an inherited site and, if it reports more than one page-cache plugin, pick one to keep, usually the one your host recommends, and deactivate the other in wp-admin before tuning anything. Measurements taken with two page caches answering tell you about whichever one won the request, not about the setting you changed.