Caching and page speedPro
W3 Total Cache MCP: separate flushes for pages, minify, objects, queries and opcode
W3 Total Cache MCP access is mostly about its many caches. Beyond purging pages, an AI agent working through GoBuildWP Pro can clear cached minified bundles for later regeneration, empty the object or database cache, clear compiled PHP after a file change, and rotate browser-cache query strings, each as a separate action. Settings go through the W3TC Config object, and because that configuration lives in a file, an individual settings change has no automatic undo.
w3tc- Layer
- page
- Declared purge scopes
allurlpost- Shared keys
- 8
- Detected by
- constant W3TC_VERSION
Installed class, method or listener checks and per-layer results determine whether a purge ran. Neither a declaration nor a returned ran flag proves public freshness.
- Edition
- Pro
- Abilities
- 16
- Requires
- WordPress 6.9+, PHP 8.0+
Before changing cache settings, inspect captured drivers and not_captured. After reverting, inspect restored, deleted, not_restored, verified and purged_layers. Use a separate cache-purge result when you need details for each layer. Storage verification checks captured values; it does not establish functional recovery or public freshness. Revert may overwrite later settings, and vendor configuration regeneration or a re-save can still be required.
Check each measurement run’s fetched_via before treating it as public-path evidence. cache-verify-in-browser supplies checks and does not operate a browser. Automatic purge coalesces targets within the request and runs on shutdown; it is not necessarily one immediate flush per call. Verify generated files, object/page/edge caches and actual visitor behavior separately.
Abilities
Flushes, settings and snapshots on W3TC
| Ability | What it does here | Undo and limits |
|---|---|---|
cache-list-actionscache-run-action | Five actions, all reached through W3TC\Dispatcher's CacheFlush component: flush_minify clears combined bundles after a stylesheet edit so they are built again on a later request, flush_object_cache and flush_database_cache empty cached objects and SQL results, flush_opcode_cache clears compiled PHP after a plugin or theme file changes, flush_browser_cache rotates asset query strings. | None deletes content, all run inline, and none can be reversed. An action whose entry point does not resolve on this install is refused, not faked. |
cache-purgecache-warm | Page purges call w3tc_flush_all(), w3tc_flush_url() or w3tc_flush_post(), then warming requests the URLs you plan to measure so W3TC can cache them again. | No stored state changes. A CDN edge in front of the site keeps its copy. |
cache-get-settingscache-set-settings | The shared map is short: pgcache.enabled, pgcache.lifetime, browsercache.enabled, objectcache.enabled, the CSS and JS minify switches, lazyload.enabled and cdn.enabled. Logged-in caching is left out on purpose because pgcache.reject.logged has the opposite sense. | Only cdn.enabled is gated here. The ledger records these writes as not reversible. |
cache-set-native | Reaches any W3TC key by its dotted name, from the ConfigKeys.php list, through the same Config save. | Confirm every time, and no ledger undo; note the old value first. |
cache-list-presetscache-apply-preset | Aggressive lands exactly like balanced on W3TC, since none of the combine or defer keys map, so no preset needs confirm on this plugin. | A preset has no rollback here either; take an experiment first. |
cache-begin-experimentcache-revert-experimentcache-check-setupcache-measure-pagecache-verify-in-browser | Experiments snapshot W3TC through its Config object and revert through save(), then compare against a freshly loaded Config. Setup detects W3TC_VERSION; measurement and browser checks work as on any page cache. | If the experiment lists w3tc under not_captured, nothing will undo a W3TC change automatically. |
Reference: /docs/reference/cache
Shared cache module; do not add this count across drivers. Edition and effect labels describe the source catalogue. The installed schema, dependency versions, licence, WordPress capability, safety profile and per-ability policy determine availability; labels alone do not prove confirmation or recovery.
Limits
Where W3TC is stricter than other caches
- No per-change undo: settings, presets and native writes are all recorded as irreversible, because restoring an option row W3TC does not read would report success and change nothing.
- Start any tuning session with cache-begin-experiment; it is the only automatic way back.
- Logged-in page caching is not offered as a shared key. Writing pgcache.reject.logged natively means working with its inverted sense.
- An action reporting ran means W3TC's flush was called without error, not that every backend agreed.
Data model
A configuration file, not an option row
By default W3TC keeps its configuration in a PHP file under wp-content/w3tc-config, and mirrors it into the w3tc_config option only when W3TC_CONFIG_DATABASE is defined. The supported way in is its Config object, whose save() also rewrites the generated config file and the .htaccess rule blocks several of its engines depend on.
There is no call that returns the whole configuration, so GoBuildWP reads the key list W3TC ships in ConfigKeys.php and asks the Config object for each entry. That list is the full surface cache-set-native can address.
The caches themselves are spread across whatever backends are configured; W3TC's listing names disk, Redis, Memcached, APC and APCu among them, for page, database, object and browser caching. For an agent this means no option row to snapshot, which is why the change ledger treats W3TC settings writes as irreversible.
Settings are set on the live W3TC Config object and committed with save(), the path that regenerates its config file and rule blocks. Writing the option row directly would leave those files out of step, so GoBuildWP never does.
Shared key → W3 Total Cache setting
page_cache.enabled → pgcache.enabledpage_cache.ttl → pgcache.lifetimebrowser_cache.enabled → browsercache.enabledobject_cache.enabled → objectcache.enabledcss.minify → minify.css.enablejs.minify → minify.js.enableimages.lazyload → lazyload.enabledcdn.enabled → cdn.enabled
Worked example
A stylesheet edit that will not show up
Expected outcome to verify on the installed stack; this sequence has not been recorded as a runtime test.
The new styles are served while the rest of the page cache stays warm. If the change still does not appear, check-setup's edge layers, or a flush_opcode_cache after a PHP file change, are the next places to look.
Minify flush clears cached bundles that rebuild later. Preserve browser-cache query-string and version semantics. After configuration changes, check expected content, generated rules and any required native save.
I changed the theme's CSS an hour ago and the homepage still looks the same. Fix it without clearing everything.
wppilot/cache-check-setupReadConfirms W3TC is the active layer, whether minify is part of it, and whether an edge sits in front.
wppilot/cache-run-actionConfirm firstflush_minify discards the combined CSS and JS bundles; W3TC builds new ones from the edited file when a page next requests them.
wppilot/cache-purgeWriteScope url on the homepage, so its cached HTML stops pointing at the old bundle.
wppilot/cache-warmWriteRequests the homepage and reports whether the response came back cached.
wppilot/cache-measure-pageReadShows the render-blocking stylesheet count and cache status on the rebuilt page.
A suggested sequence from the ability reference, not a recorded run.
Other plugins
W3TC next to other caches
- W3TC's own instructions are to deactivate and uninstall any other caching plugin.
- Redis Object Cache's changelog records stopping W3 Total Cache from overwriting its object-cache.php drop-in, so decide which plugin owns the object cache before enabling objectcache.enabled.
- Autoptimize's clear-all tries to flush W3TC's page cache as well, and cache-purge covers both layers in one call.
ConfigKeys.php, redacted backends and confirmed flushes
What W3 Total Cache's ConfigKeys.php decides about an agent's reach
W3 Total Cache MCP access through GoBuildWP depends on a file most owners never open. W3TC has no call that returns its whole configuration, so GoBuildWP reads the key list the plugin ships in ConfigKeys.php and asks the Config object for each entry. If that file is missing or unreadable on an install, the native dump comes back empty, cache-set-native has no key it can read back and refuses everything, and cache-begin-experiment lists w3tc under not_captured.
That combination matters because W3TC writes have no ledger undo. With the experiment snapshot missing as well, there is no automatic way back, so a tuning session should stop there and the current values be copied out of the W3TC screens first. When the file is present, keys are W3TC's dotted names such as pgcache.lifetime or minify.css.enable, and the driver compares restored values against a freshly loaded Config. The experiment response reports verified and not_restored; it does not expose the driver's per-key mismatched list. Inspect those outcomes and read the settings again before continuing.
Memcached usernames and CDN logins in a W3TC settings dump
W3TC keeps credentials for its backends in the same configuration as its switches. GoBuildWP withholds them: any key whose name reads as a credential, plus a named list for this plugin that includes cdn.ftp.user, cdn.azure.user, cdn.google_drive.client_id and the Memcached usernames for the page, object, database and minify caches, comes back as [redacted] and is listed in redacted_keys. An empty credential is shown empty, so you can still tell whether a CDN or Memcached server is configured.
The marker works in reverse too: sending [redacted] back through cache-set-native keeps the stored secret rather than saving the literal text. The agent never sees the existing value, so rotating a CDN or Memcached password belongs in W3TC's own screens, where you type it yourself.
W3TC flushes under Production Safe, and after a plugin update
cache-run-action is classed destructive as a whole, so the safety layer asks for confirmation on every call, a harmless flush_minify included. Read Only refuses all five W3TC actions along with purge and warm. An Abilities Hub rule cannot remove that confirmation, because rules only add requirements, so the practical approach is to approve the flush together with the change that made it necessary.
After updating plugins or the theme through GoBuildWP's update flow, the order that matches W3TC's separate caches is flush_opcode_cache so PHP stops running old files where OPcache holds them, flush_minify if the update shipped CSS or JavaScript, then cache-purge for the pages and cache-warm for the ones you are about to measure.
- "List the W3TC actions on this site and which of them resolve on this install. Run nothing."
- "Start an experiment, set pgcache.lifetime to one day, and show me what the experiment captured."
- "We just updated the theme. Flush opcode and minify, purge the homepage, warm it and measure it."
Questions
W3 Total Cache questions
Why can't the agent undo a W3 Total Cache settings change?
W3TC reads its configuration from a file, so restoring an option row would not change what it runs. The experiment snapshot, taken through its Config object, is the supported way back.
Which flush should I ask for after editing theme CSS or JavaScript?
flush_minify, followed by a purge of the affected URLs. After changing PHP files on a server with OPcache, flush_opcode_cache as well.
Does the agent call W3TC's WP-CLI flush commands?
No. It calls the PHP entry points directly: the w3tc_flush functions and the CacheFlush component. W3TC's wp w3-total-cache flush command stays available to you.
Where these facts come from
GoBuildWP behaviour is taken from the plugin source and the ability reference; third-party details from the vendor documentation below, checked by the GoBuildWP team.
W3 Total Cache is a separate product; no partnership or endorsement is implied.