Kaburu Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
# 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)

| Drop-in | Count | Sites |
|---------|-------|-------|
| Till Kruss `redis-cache` (v2.8.0) | 8 | aberdeenrda, billing.myretonmarquees, claybusters, doctorfin, ggsgenerators, kaburusvr.uk, pilates-edinburgh, touchwell |
| FastPixel own drop-in (FP v1.6.0) | 3 | 24hrresponse, myretonmarquees, womenunlimited |
| None (no object cache) | 9 | bankhousecatering, chippy.kaburu.co.uk, dm-ph, friendscic, jafricasafari, kaburu.co, kaburu.co.uk, l8.kaburu.co.uk, l8waterhygiene |

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).