Pro module14 abilities

Cache and page speed

These abilities register when Cache and page speed is detected on the site and a Pro licence is active. If either is missing the module stays absent rather than failing at call time.

At a glance

Cache and page speed registers 14 abilities: 6 that only read, 5 that write, and 3 marked destructive. That split is the practical answer to how much of this module can run unattended. Reads cost nothing and are safe to repeat, so discovery is the part to be generous with; the writes are where review belongs, and the destructive calls stop for an explicit confirmation every single time regardless of which profile is active.

Availability on your site

The Cache and page speed module needs three things at once: WPPilot Free as the MCP foundation, an active Pro licence, and the companion plugin detected on the site. Miss any one and the module does not register, which is deliberate: an ability that appears in the tool list but fails at call time is worse than an ability that was never offered. What the connected agent can actually call is then narrowed twice more: by the safety profile active on the site, and by the WordPress capabilities of the user behind the credential. A read that succeeds for an administrator can be absent entirely for an editor.

Every write these abilities perform is recorded in the change ledger, and destructive calls can be routed through the approval queue so a person signs off before anything is applied. A successful tool result means the operation returned, not that the front end, the cache, and every dependent template are correct: that still needs a look.

Reads

Available in every safety profile, including Read Only. Inspection costs nothing and is not rate limited.

Ability	What it does
`wppilot/cache-check-setup`Check Cache Setup	Reports every caching layer in front of this site: the page-cache and asset-optimisation plugins that are active (with version, driver key, whether their settings can be read and written, and whether they are mapped onto the shared canonical vocabulary or reachable only by their own key names), whether a persistent object cache is in use, whether WP_CACHE is on with an advanced-cache.php drop-in, and which CDN, WAF or host edge layers answered the site's own request headers. Also lists the purge scopes each layer actually supports on this install, and whether automatic purge-after-write is enabled. A site normally runs more than one layer at once — an asset optimiser in front of a page cache in front of a CDN — so this returns a LIST, not a single winner. Call this first before any other cache ability.
`wppilot/cache-get-settings`Get Cache Settings	Reads one cache layer's configuration in a canonical vocabulary shared across every supported plugin, so the same key means the same thing whether the site runs LiteSpeed, WP Rocket or W3 Total Cache. Groups: page_cache, browser_cache, object_cache, css, js, images, fonts, cdn, preload, database. `unsupported` lists the canonical keys this plugin has no equivalent for — treat those as absent features, not as settings that failed to read. `risky_keys` marks the ones cache-set-settings will refuse without confirm=true. Set include_native=true to also get the plugin's ENTIRE settings row — every option it owns, not only the ones the canonical model names — with `native_complete` saying whether it fit inside the size cap. That is how you reach the rest of a plugin: LiteSpeed keeps 187 settings and 23 of them are canonical, so the other 164 appear there and are writable through cache-set-native. Omit `driver` when the site has exactly one page cache; when several are stacked the call names them and asks you to choose.
`wppilot/cache-list-actions`List Cache Actions	Lists the cache operations available on this site that are actions rather than settings — running a crawler so pages are cached before a visitor arrives, preloading the page cache, cleaning the database that every uncached page load has to query. Each entry says whether it is destructive, whether it blocks while it works, and whether its entry point actually resolves on this install; an action listed as unavailable is one the plugin does not expose in a way that can be called from here. Settings are cache-get-settings and cache-set-settings; this is the other half.
`wppilot/cache-list-presets`List Cache Presets	Lists the named cache configurations — conservative, balanced, aggressive — with, for each one, the canonical keys it sets, which of those the active plugin actually supports, which are confirmation-gated, and which would change from the site's current values. Read this before cache-apply-preset: the "would change" list is the honest preview of what applying it does here, on this site, with this plugin, rather than what the preset says in the abstract.
`wppilot/cache-measure-page`Measure Page Delivery	Fetches one URL of this site from the server and reports what the response itself proves: time to first byte across repeated requests, whether the cache reported a HIT or a MISS (x-litespeed-cache, x-cache, cf-cache-status and friends), HTML byte weight and whether it was compressed, how many render-blocking stylesheets and head scripts the document loads, how many images ship without width/height or a loading attribute, and whether any font is preloaded. This is server-side delivery, NOT a Lighthouse score and NOT Core Web Vitals — it cannot see LCP, CLS or INP, because those only exist once a browser renders. Measure those in a browser and use this for the half a browser cannot tell you: whether the cache actually engaged, and what the document is asking the browser to do before it can paint. If the server cannot reach its own public URL — normal on containerised or proxied sites, where the port in the site URL belongs to the host — it retries once on the local interface with the site's Host header and reports that in `runs[].fetched_via` rather than hiding it.
`wppilot/cache-verify-in-browser`Verify In Browser	Names what an optimisation is most likely to have broken on one URL, and hands back the exact browser checks that would prove it either way. This ability does NOT run a browser: WordPress has no browser to run, and a headless one bolted into PHP would be a second thing to trust rather than the thing the visitor actually sees. It reads the delivered HTML, marks the elements a cache plugin most often damages — an above-the-fold image that got lazy-loaded, an image served over http on an https page, an image with no intrinsic size — and returns `browser_checks`, each one a snippet to run in a real browser you have open, with the result that counts as a pass. Run the checks, then fix what fails, one at a time. The point is that `cache-set-settings` reporting `applied: true` for every key proves only that the option row was written; it cannot see that the header logo is now a transparent placeholder, and neither can any server-side audit. A browser can. It also returns `pagespeed`: the PageSpeed Insights report URLs for both form factors and the snippet that reads the scores and failing audits out of the page, so the score comes from the same browser and needs no API key — the keyless PSI API quota is shared globally and answers 429 for most of the day. Where the site is not reachable from the public internet it says so instead of sending the agent to a report that cannot run. It also returns `blocked_by_environment`: what is wrong here that no WordPress setting can fix, and the steps for whoever owns that layer. That list exists because the expensive failure is a silent one — a setting written, read back correctly, reported as applied, and doing nothing on the wire because the thing that would carry it out lives outside WordPress. Without it an agent tunes the same key repeatedly and reports progress no visitor experiences. Use `cache-measure-page` for the delivery numbers this cannot see, and this for the render damage and the public score those numbers cannot see.

Writes

Gated by the active profile and your WordPress capabilities. Rate limited to 120 per minute per credential.

Ability	What it does
`wppilot/cache-apply-preset`Apply Cache Preset	Applies a named preset to the active cache plugin and purges it, as one change-ledger entry that wppilot/rollback-change can undo in full. Keys the plugin does not support are skipped and reported. The aggressive preset contains confirmation-gated keys and is refused without confirm=true; conservative and balanced apply without one. Prefer cache-set-settings with a single key when you are tuning against measurements — a preset moves many settings at once, and if the site gets slower or breaks you will not know which one did it.
`wppilot/cache-begin-experiment`Begin Cache Experiment	Snapshots the settings of every cache layer on this site and returns an experiment_id. Call it before a tuning session; if anything you change afterwards makes the site slower or breaks it, cache-revert-experiment puts every layer back to this exact state in one call and purges. This spans plugins, which per-change rollback does not: on a site running an asset optimiser in front of a page cache, one id restores both. It changes nothing by itself. Only the newest five experiments are kept.
`wppilot/cache-purge`Purge Cache	Purges cached HTML across every caching layer detected on this site at once — page-cache plugin, asset optimiser, object cache — because a site that stacks two of them and purges one keeps serving a mix of old and new. `scope` is "all" (default), "url", or "post". A targeted scope on a plugin that only exposes a whole-cache purge widens to a full purge and reports that it did, rather than silently doing nothing. The url must belong to this site. Returns a per-layer result saying exactly which entry point was called, so a layer that could not be purged is visible rather than assumed. This does NOT purge a CDN or WAF edge in front of WordPress (Cloudflare, Sucuri, a host edge) — cache-check-setup lists those under edge_layers and they need their own purge.
`wppilot/cache-set-settings`Set Cache Settings	Writes cache settings using the canonical vocabulary from cache-get-settings, then purges the layer so the change is actually in effect. Pass `settings` as nested groups, e.g. {"images":{"lazyload":true},"page_cache":{"ttl":3600}}. Two tiers: most keys apply straight away, but the ones that routinely break sites — css.combine, css.critical, css.unused_css_removal, css.defer, js.combine, js.defer, js.delay, cdn.enabled, cdn.hosts and page_cache.cache_logged_in — are refused unless confirm=true, and the refusal names exactly which ones. Keys this plugin has no equivalent for are reported as unsupported rather than silently dropped. Every write is recorded in the change ledger with a before-image, so wppilot/rollback-change restores the previous values exactly. Change one thing at a time and re-measure: a batch that makes a site slower or breaks it gives you no way to tell which key did it.
`wppilot/cache-warm`Warm Cache	Requests up to ten URLs of this site so the page cache rebuilds them before anyone measures or visits. Use it immediately after a purge: the first request to a purged URL pays for the whole page build, so a benchmark taken then measures WordPress rendering rather than cache delivery, and reads far worse than the site actually performs. Reports per URL whether the fetch succeeded, how long it took, and whether the response came back reporting a cache HIT — the second of which tells you whether the warm actually stuck. Defaults to the home page when given nothing.

Destructive

Marked destructive in the source, so each call needs an explicit confirmation flag, every time.

Ability	What it does
`wppilot/cache-revert-experiment`Revert Cache Experiment	Restores every cache setting captured by cache-begin-experiment and purges all layers. Use it the moment a tuning step makes things worse: a page that gained console errors, a layout that shifted, a measurement that regressed. Reports which option rows were restored and whether the result matches the snapshot. One caveat worth knowing: this writes the option rows back directly, so a plugin that also generates rewrite rules or an on-disk config from its settings screen may need that file regenerated — re-saving once in the plugin's own settings screen does it.
`wppilot/cache-run-action`Run Cache Action	Runs one of the actions listed by cache-list-actions. Refuses an action whose entry point does not resolve on this install rather than reporting a success nothing performed. Destructive actions — anything that deletes rows rather than rebuilding a cache — require confirm=true, and are NOT reversible: the change ledger restores settings, not deleted revisions or comments. A blocking action runs inline and can take a long time on a large site; a non-blocking one queues work and returns immediately, so re-measure later rather than straight after. `ran` means the entry point was called and did not throw — not that the plugin did the work, which it may decline for its own reasons (a crawler with no sitemap crawls nothing). Confirm through the plugin or by re-measuring.
`wppilot/cache-set-native`Set Native Cache Setting	Writes any of a cache plugin's own settings by its native key — the escape hatch for everything outside the canonical model, which covers only what several plugins share. LiteSpeed has 187 settings and 23 are canonical; guest mode, ESI, per-asset exclusions, the crawler schedule and the rest are reachable here. Read them first with cache-get-settings include_native=true: this ability refuses any key it cannot read back beforehand, so a typo or a key renamed between plugin versions is rejected instead of creating a junk option the plugin ignores. Writes go through the plugin's own save path, so whatever it does on save — regenerating a config file, rewriting .htaccess, flushing derived state — still happens. Values are coerced to match the type already stored. Always requires confirm=true: these keys carry no risk tiering, no validation beyond the plugin's own, and no guarantee WPPilot understands what they mean.

PreviousBuddyPress NextContact Form 7