Caching and page speedPro
Check the Redis connection before flushing the object cache
Before changing Redis Object Cache, answer two questions: is the object-cache.php drop-in really serving WordPress from Redis, and what happens when an agent flushes it. Connection details live in WP_REDIS_* constants inside wp-config.php, which no cache ability edits, so the useful work here is diagnosis, a whole-cache flush, and reading the plugin's few option rows by name.
redis_cache- Layer
- object
- Declared purge scopes
all- Shared keys
- None
- Detected by
- plugin folder redis-cache
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.
Data model
Where Redis Object Cache keeps what matters
Almost none of its real configuration is in the database. Per the plugin's readme, host, port, password, database index, key prefix, client library (PhpRedis, Predis or Relay) and a maximum TTL are defined as WP_REDIS_* constants in wp-config.php, above the line that loads wp-settings.php. The caching happens in wp-content/object-cache.php, a drop-in WordPress loads before any plugin, and the cached objects themselves sit in the Redis server, outside WordPress entirely.
GoBuildWP declares two option-name prefixes for this driver, redis_object_cache and wp_redis_, and accepts only rows under them as belonging to the plugin. Those rows can be read with cache-get-settings and written by exact name, yet they are bookkeeping around the drop-in, not the connection. Pointing the site at another Redis server, switching database index or setting WP_REDIS_DISABLED are file edits for whoever controls wp-config.php.
An object cache holds query results and computed values, not rendered pages, so nothing here maps onto page-cache vocabulary and there are no URLs to exclude.
Option name prefixes
redis_object_cachewp_redis_
Object-cache drop-in: it has no page-cache settings to map. Its own options are readable and writable by name; status and flush are the operations that matter.
Other plugins
Other object caches and the page cache in front
- Only one object-cache.php can exist. The plugin's changelog says it stops W3 Total Cache, LiteSpeed Cache and Performance Lab from overwriting its drop-in, and that it does not compete with Object Cache Pro.
- A page cache in front of Redis is the ordinary setup. One cache-purge reaches both, and each is reported as its own layer result, so a page cache that failed to purge is visible even when the flush succeeded.
- Several sites sharing one Redis server should be kept apart with WP_REDIS_DATABASE or WP_REDIS_PREFIX, as the vendor's FAQ advises. Keep that separation in place before letting any agent flush.
Abilities
What each cache ability does on a Redis-backed site
| Ability | What it does here | Undo and limits |
|---|---|---|
cache-check-setup | Lists redis_cache as a layer of kind object once the redis-cache plugin folder is active, and reports object_cache.active and object_cache.backend alongside it. Backend reads redis only when WordPress is using an external object cache and the plugin's class or WP_REDIS_VERSION is present. | purge_scopes.all shows true even with the drop-in switched off, because wp_cache_flush() is a WordPress core function. Trust object_cache.active, not the layer entry, to decide whether Redis is serving. |
cache-get-settingscache-set-native | Return and change rows under redis_object_cache and wp_redis_ by their stored names. Pass driver redis_cache: next to a mapped page cache, a call without a driver picks the page cache instead. | Each write needs confirm=true and is refused for any name the ability cannot read back first. The WP_REDIS_* constants are PHP definitions, so they never appear in the native dump. |
cache-purgecache-warm | Every purge of this layer calls wp_cache_flush(); a url or post request widens to the entire object cache and the layer result says it widened. Warming afterwards requests pages so the first rebuilt queries land back in Redis. | There is no selective flush. A flush restores nothing if it was a mistake, because the ledger has no state to put back. |
cache-set-settingscache-apply-presetcache-list-presets | Report every canonical key as unsupported and skip every preset key: an object cache has no page_cache, css or js setting for them to mean. | No risk tiering applies on this layer. |
cache-list-actionscache-run-action | Show nothing for this driver. GoBuildWP declares no preload, crawl or clean-up action for Redis Object Cache. | Drop-in management stays with the plugin's screen or wp redis enable, disable and update-dropin on the command line. |
cache-begin-experimentcache-revert-experimentrollback-change | An experiment captures whatever rows exist under the two prefixes; rollback-change puts back the row one native write touched. | If no option exists under either prefix, this layer contributes nothing to a snapshot. |
cache-measure-pagecache-verify-in-browser | Repeated server-side fetches are where a working object cache can show, as shorter builds of uncached pages. | No response header announces a Redis hit, so the HIT or MISS measure-page reports belongs to a page cache or edge, not to this layer. |
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.
Worked example
Confirm Redis is serving before blaming slow admin screens
Expected outcome to verify on the installed stack; this sequence has not been recorded as a runtime test.
The user learns whether Redis is really in use and ends with an empty object cache. When object_cache.active comes back false, the fix sits outside GoBuildWP: enable the drop-in from the plugin's settings or with wp redis enable, or correct the WP_REDIS_* constants.
A whole object-cache flush can affect other sites sharing the backend, database or prefix. Check a representative origin-generated dynamic request and backend evidence; homepage HIT or TTFB alone does not prove Redis refill. Purges are coalesced within the request.
The dashboard feels sluggish. Is Redis actually being used, and can you flush it?
wppilot/cache-check-setupReadReturns redis_cache in layers plus object_cache. active true with backend redis means the drop-in is loaded; active false means the plugin is on while WordPress runs without it.
wppilot/cache-get-settingsReadWith driver redis_cache and include_native true, lists the rows under the plugin's prefixes and whether the dump was complete.
wppilot/cache-purgeWriteScope all. The per-layer result names wp_cache_flush() as the entry point that ran, next to any page cache that was purged in the same call.
wppilot/cache-measure-pageReadSeveral runs of the home page after the flush give server timings to compare. They cannot show on their own that Redis is refilling, because no response header reports object-cache hits; treat object_cache.backend from check-setup as a lead. Confirm drop-in ownership and Redis backend activity independently before attributing timings or refill to Redis.
A suggested sequence from the ability reference, not a recorded run.
Limits
Where the Redis integration stops
- wp-config.php is out of reach for every cache ability, so connection host, port, password, database and prefix can be neither changed nor read through them.
- Purge-after-write is on by default, and on this layer each automatic purge is a full object-cache flush. Setting the wppilot_cache_auto_purge option to 0, or returning false from the filter of the same name, turns it off.
- Native row writes and experiments can be undone with rollback-change or cache-revert-experiment; flushes cannot.
- If Redis becomes unreachable and the site stops loading, the vendor's remedy is deleting object-cache.php or defining WP_REDIS_DISABLED. Neither is an ability, so keep file access to hand.
Drop-in ownership, flush storms and read-only checks
When object_cache.backend says redis but another plugin wrote object-cache.php
A Redis Object Cache MCP check starts with cache-check-setup, and its backend field needs reading with care. GoBuildWP reports redis when WordPress is using an external object cache and the Redis Object Cache class or WP_REDIS_VERSION is loaded. It does not open object-cache.php to see who wrote it. If W3 Total Cache, LiteSpeed Cache or another plugin owns the drop-in while Redis Object Cache is merely active, the report can still say redis.
Treat backend redis as a lead rather than proof. Confirm who owns the drop-in in Redis Object Cache's own status view, and if W3 Total Cache is installed, read its object_cache.enabled with cache-get-settings and driver w3tc, since that plugin can claim the same file. A backend of unidentified means something other than the Redis, Docket and SQLite backends GoBuildWP recognises is caching objects.
When object_cache.active is false, cache-verify-in-browser adds a no_persistent_object_cache entry to blocked_by_environment, names object_cache.enabled as inert and gives the host-side steps: provision Redis, point the plugin at it, confirm the drop-in landed. The entry disappears once the drop-in is serving, which makes it a clean before-and-after check for a hosting ticket.
Why thirty agent edits can mean thirty Redis flushes
Purge-after-write runs at the end of each request that carried a GoBuildWP write. If the write named a post, the purge is post-scoped, and Redis Object Cache has no post or URL entry, so its layer widens to wp_cache_flush() every time. An agent editing thirty posts one call at a time therefore empties Redis thirty times, and each uncached request in between rebuilds its queries from the database.
For batch work, switch automatic purging off first by setting the wppilot_cache_auto_purge option to 0 or returning false from the filter of the same name, make the edits, then run one cache-purge with scope all and switch it back. The same switch also stops the page cache purges for those edits, so the closing purge is not optional.
Running a Redis Object Cache health check on the Read Only profile
None of the diagnosis needs write access. cache-check-setup, cache-get-settings with driver redis_cache, cache-measure-page and cache-verify-in-browser are read abilities, so they run under the Read Only safety profile for a user with manage_options. cache-purge and cache-warm are writes and are refused there; Production Safe permits them subject to per-ability and approval policy.
A confirmation rule for cache-purge requires a confirm flag, which the client can supply by default. Enable the configured human-approval mode when a person must authorize each flush; inspect the rule and approval outcome before running it. The rule applies across cache layers, so review its scope. The security page covers how profiles and per-ability rules combine, and every cache ability, the read ones included, is Pro.
Redis questions an owner can hand the agent
These are phrased the way the work usually arrives, and each one stays inside what the abilities can actually see.
- "Does check-setup report Redis as the object-cache backend, and is WordPress using the drop-in? Read only, no flush."
- "I'm about to update thirty product descriptions. Turn off auto purge, make the edits, flush once at the end and turn it back on."
- "After the flush, measure the shop page a few times and report the timings, without treating them as proof that Redis is refilling."
Questions
Redis Object Cache questions
Can an AI agent change the Redis host or password through GoBuildWP?
No. Those are WP_REDIS_* constants in wp-config.php, and the cache abilities reach only option rows under redis_object_cache and wp_redis_. Edit the file yourself or ask your host.
Does flushing Redis from the agent also clear my page cache?
cache-purge fans out to every detected layer, so an active page cache plugin is purged in the same call. The Redis part is always a full wp_cache_flush(), whatever scope was requested.
Can I keep a particular page out of Redis?
Not with this plugin. Its FAQ explains that it caches objects rather than URLs, so page exclusions belong to your page cache.
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.
Redis Object Cache is a separate product; no partnership or endorsement is implied.