Kaburu Wiki

# Object Cache & Redis (estate-wide)

How the WordPress object cache is wired across the managed estate, and the one gotcha in how it flushes. Audited 2026-05-28 (read-only; no changes made).

## TL;DR

- One Redis instance, `127.0.0.1`, all sites share db0 (~3160 keys). - Cache data is site-specific — keys are namespaced per site, no cross-site bleed. - Cache flush is NOT site-specific on the Till Kruss sites: with no selective-flush

config, `wp_cache_flush()` runs a full `FLUSHDB` and clears every site's keys in db0.

- Operationally low impact (sites update together), so the fix is deferred.

## Redis instance

- Host/port: `127.0.0.1:6379` (default), no auth, single instance. - All object-cache sites use db0. No `WP_REDIS_DATABASE` defined anywhere. - ~3160 keys live in db0, all sites mixed into one database.

## Object-cache drop-in — three-way split (20 sites)

Inconsistency worth noting: myretonmarquees.co.uk uses FastPixel's drop-in, but its billing.myretonmarquees.co.uk subdomain uses Till Kruss. Same client, two layers.

FastPixel page cache is on all 20 sites. Divi on all except kaburusvr.uk (the MainWP box).

## Key namespacing (data IS isolated)

Keys carry per-site prefixes, e.g. `PDLAg:post-queries`, `BZi1qCUS:posts`, `wp9b:options`, and the FastPixel sites under `fastpixel-<hash>:`. No site reads another's cached data.

## Flush behaviour (the gotcha)

The TK drop-in `flush()` only scopes to the site when BOTH `WP_REDIS_PREFIX` and `WP_REDIS_SELECTIVE_FLUSH` are defined. Neither is set on any site, so it falls to the `else` branch = full `FLUSHDB`. `FLUSHDB` ignores key prefixes and deletes everything in db0.

Result: any Till Kruss site running `wp_cache_flush()` (triggered by plugin/theme/core updates, Divi saves, FastPixel purge, or a manual flush) wipes the object cache for all 11 object-cache sites at once, including the dashboard (kaburusvr.uk).

The 3 FastPixel-drop-in sites likely flush selectively via their own `fastpixel-<hash>:` prefix (clearing only themselves) — to be confirmed before relying on it. A TK FLUSHDB still takes the FastPixel sites' keys with it regardless, since they also live in db0.

FastPixel's “Purge Object Cache” button simply calls `wp_cache_flush()` — i.e. it routes to whatever drop-in is active. Handy as a universal object-cache purge entry point if ever needed.

## Operational impact — why it's deferred

Low. Sites are updated estate-wide together (Steve via MainWP dashboard, Hermes via WP-CLI), so the caches clear around the same time anyway. The only real bite is an ad-hoc single-site clear (e.g. after a manual Divi edit on one client), which cold-starts all 11 sites needlessly. Not worth fixing right now.

## Deferred fix (if ad-hoc single-site clears ever matter)

On the 8 Till Kruss sites, in `wp-config.php`: - define a unique `WP_REDIS_PREFIX` per site - set `WP_REDIS_SELECTIVE_FLUSH` to true

The per-site prefixes the selective flush needs already exist in the keyspace, so this is config-only — no rebuild. Alternative: unique `WP_REDIS_DATABASE` per site (cleaner mental model, but Redis defaults to 16 DBs and FastPixel `dbid` would need to match).

## History / context

Original driver (years back): building Divi sites meant changes wouldn't render until a fixed chain was flushed in order — Divi builder cache → page cache (LiteSpeed/FastPixel) → Cloudflare → Redis. MainWP's flush-cache existed but sites often lost CSS alignment after updates (caches out of sync), needing a full flush. The plan was to extend MainWP's cache-clear to support FastPixel + Divi + Redis + CF, with a dashboard widget and per-site buttons.

Status (2026-05): shelved. Divi 5's rewritten cache purge resolved most of the sync pain, so a bespoke MainWP+FastPixel plugin is no longer worth building. Residual symptom seen: some Divi 5 headers occasionally revert to default CSS and need a manual purge — that's a Divi-internal cache-sync issue, not something a MainWP button would fix better.

A deepseek32b (kaburuaibox) attempt at the plugin was reviewed and rejected: structurally plausible but it invented MainWP mechanics and proposed a dashboard-side `FLUSHALL` — it had no visibility of the real estate. See also z840 (kaburuaibox).