# FastPixel — MainWP Cache Control Integration

## What This Does

Integrates FastPixel (page cache + object cache + CF purge) with MainWP's Cache Control extension so that:

- Cache Control shows **FastPixel** as the cache solution for all sites
- The **Clear Cache** button in MainWP purges FastPixel page cache AND Divi static CSS on the child site
- Auto-purge fires on plugin/theme updates via MainWP
- Bulk purge works from Cache Control → Sites

---

## Why It's Non-Standard

FastPixel is not in MainWP's official supported cache plugin list. MainWP developer docs at https://mainwp.dev/cache-control-custom-addition/ describe adding support via a PR to mainwp-child. 

**As of July 2026, no upstream PR exists.** FastPixel developer (Claude) was asked to submit one June 2026 — it never happened. This patch is now the permanent solution, not a temporary workaround.

---

## Components

### 1. mainwp-child patch (on every child site)
**File:** `/home/<domain>/public_html/wp-content/plugins/mainwp-child/class/class-mainwp-child-cache-purge.php`

Three changes made to this file:

**a) $other_cache_plugins array** — FastPixel added after AccelerateWP:
```php
'fastpixel-website-accelerator/fastpixel.php' => 'FastPixel',
```

**b) auto_purge_cache() switch** — FastPixel case added after AccelerateWP:
```php
case 'FastPixel':
    $information = $this->fastpixel_auto_purge_cache();
    break;
```

**c) fastpixel_auto_purge_cache() method** — added before class closing brace:
```php
public function fastpixel_auto_purge_cache() {
    $success_message = 'FastPixel => Cache auto cleared on: (' . current_time( 'mysql' ) . ')';
    $error_message   = 'FastPixel => There was an issue purging your cache.';
    $purged = false;

    if ( class_exists( '\FASTPIXEL\FASTPIXEL_Backend_Cache' ) ) {
        $cache = \FASTPIXEL\FASTPIXEL_Backend_Cache::get_instance();
        if ( method_exists( $cache, 'purge_all' ) ) {
            $purged = $cache->purge_all();
        }
    }

    if ( ! $purged ) {
        $cache_dir = WP_CONTENT_DIR . '/cache/fastpixel-website-accelerator';
        if ( is_dir( $cache_dir ) ) {
            file_put_contents( $cache_dir . '/invalidated', json_encode( array( 'time' => gmdate( 'Y-m-d H:i:s' ) ) ) );
            $purged = true;
        }
    }

    if ( class_exists( '\ET_Core_PageResource' ) ) {
        \ET_Core_PageResource::remove_static_resources( 'all', 'all' );
    }

    if ( $purged ) {
        update_option( 'mainwp_cache_control_last_purged', time() );
        return $this->purge_result( $success_message, 'SUCCESS' );
    } else {
        return $this->purge_result( $error_message, 'ERROR' );
    }
}
```

⚠️ **Critical namespace note:** The file is in the `MainWP\Child` namespace. All external class references MUST have a leading backslash (`\FASTPIXEL\...`, `\ET_Core_PageResource`) or PHP resolves them as `MainWP\Child\FASTPIXEL\...` and fatals. This was the bug in the first rollout attempt.

---

### 2. kaburu-fp-purge-endpoint plugin (on every child site)
**File:** `/home/<domain>/public_html/wp-content/plugins/kaburu-fp-purge-endpoint/kaburu-fp-purge-endpoint.php`

**Purpose:** Shim plugin. MainWP child's `check_cache_solution()` runs at `plugins_loaded` priority 99 and overwrites `mainwp_cache_control_cache_solution` — since FP isn't in its list, it sets "Plugin Not Found". This plugin hooks at priority 100 and corrects it back to "FastPixel".

**v3.2.0 (2026-07-07):** Simplified — removed `is_plugin_active()` check (doesn't work on frontend). If this plugin is active, FastPixel is present.

```php
<?php
/**
 * Plugin Name: Kaburu FP Cache Solution
 * Plugin URI:  https://kaburu.co.uk
 * Description: Ensures MainWP Cache Control detects FastPixel.
 * Version:     3.2.0
 * Author:      Kaburu
 */
defined('ABSPATH') || exit;
add_action('plugins_loaded', function() {
    update_option('mainwp_cache_control_cache_solution', 'FastPixel');
}, 100);
```

Once the FP PR is merged into mainwp-child upstream (unlikely), this plugin can be deactivated and deleted from all sites — it'll be redundant.

---

### 3. Patch script
**File:** `/usr/local/bin/kaburu-apply-fastpixel-patch.sh`

Re-applies the mainwp-child patch to a single site. Idempotent — skips already-patched sites.

**Usage:**
```bash
# Single site
/usr/local/bin/kaburu-apply-fastpixel-patch.sh /home/example.com/public_html

# Entire estate after mainwp-child update
for d in /home/*/public_html; do /usr/local/bin/kaburu-apply-fastpixel-patch.sh $d; done
```

---

## Sites Covered (23 total)

All sites with both mainwp-child and fastpixel-website-accelerator installed:

24hrresponse.com, aberdeenrda.co.uk, bankhousecatering.co.uk, billing.myretonmarquees.co.uk, chippy.kaburu.co.uk, claybusters.scot, dm-ph.com, doctorfin.co.uk, friendscic.org, ggsgenerators.co.uk, jafricasafari.com, kaburu.co, kaburu.co.uk, kaburusvr.uk, l8.kaburu.co.uk, l8waterhygiene.co.uk, longniddrybowlingclub.com, longniddrybowlingclub.co.uk, myretonmarquees.co.uk, pilates-edinburgh.co.uk, rainbowvapes.co.uk, rf.kaburu.co, touchwell.co.uk, womenunlimited.africa

---

## Maintenance — After mainwp-child Updates

The patch in `class-mainwp-child-cache-purge.php` will be **overwritten** when mainwp-child updates via MainWP. The `kaburu-fp-purge-endpoint` plugin will survive updates fine.

**After any mainwp-child update:**
```bash
for d in /home/*/public_html; do /usr/local/bin/kaburu-apply-fastpixel-patch.sh $d; done
```

Then sync in MainWP Cache Control to verify all sites show FastPixel.

---

## Other Cache-Related Changes Made (2026-06-12)

- **redis-cache plugin** removed from 8 sites (aberdeenrda, billing.myretonmarquees, claybusters, doctorfin, ggsgenerators, kaburusvr, pilates-edinburgh, touchwell) — FastPixel handles Redis object cache natively via its Object Cache tab
- **kaburu.co.uk** had LiteSpeed Cache active alongside FP — deactivated
- **CF purge token** (all zones, cache purge only): `cfut_OpvqdoJwDsVZEXpnEueW7ixGnKhDIhXXIQLcfCmfb0a5775a` stored at `/root/.secrets/cloudflare-fastpixel-purge` on kaburusvr — injected into FP settings on all sites via WP-CLI
- **CF zone IDs** injected into all sites that were missing them
- **aberdeenrda privacy policy** had corrupted guid (`httpss://`) causing FP 404 error — fixed directly in DB
- **FP auto-purge on MainWP updates** — works natively since MainWP child triggers WP core update hooks which FP hooks into. Confirmed working.

---

## How the Purge Chain Works

```
MainWP Cache Control UI → Clear Cache button
  → AJAX: mainwp_cache_control_purge_cache_all
  → mainwp_fetchurlauthed (dashboard → child, encrypted channel)
  → cache_purge_action() on child
  → MainWP_Child_Cache_Purge::auto_purge_cache('true')
  → reads mainwp_cache_control_cache_solution option → 'FastPixel'
  → fastpixel_auto_purge_cache()
  → FASTPIXEL_Backend_Cache::purge_all() (writes invalidated file to cache dir)
  → ET_Core_PageResource::remove_static_resources('all','all') (Divi CSS)
  → returns SUCCESS + timestamp
  → MainWP logs Last Purged
```

---

## Deployment Status (2026-07-07)

**24/24 sites deployed.** All WordPress sites with mainwp-child now have:
- Patch in `class-mainwp-child-cache-purge.php` (3 additions)
- Shim plugin `kaburu-fp-purge-endpoint` v3.2.0 active
- Verified end-to-end on ggsgenerators.co.uk + friendscic.org — MainWP update triggered cache purge, all 4 layers cleared

**⚠️ When verifying:** always use WP-CLI (`wp option get mainwp_cache_control_cache_solution`) not direct MySQL. FastPixel's Redis object cache holds the active value — direct DB queries may return stale data.

## What Still Needs Doing

- [x] Deploy patch + shim to remaining sites — done 2026-07-07, 24/24
- [ ] Verify MainWP Cache Control shows "FastPixel" for all sites after next sync
- [ ] Set up post-update auto-repatch cron (see Maintenance section)

---

## What "By The Book" Would Look Like

The correct long-term solution is a PR to https://github.com/mainwp/mainwp-child adding FastPixel to `class-mainwp-child-cache-purge.php` officially. The code in this document is exactly what that PR should contain. 

**Reality (July 2026):** No PR exists. FastPixel dev (Claude) never delivered. The patch is permanent. If an upstream PR ever materializes:

1. Delete `kaburu-fp-purge-endpoint` plugin from all sites
2. Stop running the patch script after updates
3. Done