WP Manifestindependent plugin directory
manifest / performance / fastcgi-cache-manager

FastCGI Cache Manager

Per-URL Nginx (FastCGI) cache purging and scheduled cache warming for WordPress and WooCommerce — with a direct cache-key adapter that needs no special nginx module, plus a full-zone fallback for anything else.

by Alamin · github.com/dev-alamin/fastcgi-cache-manager · website

★ 0stars

Install

Download source zip No release zip yet

This is the repository archive. It installs, but the folder name will carry the branch suffix and updates will not flow.

Install straight from GitHub with WP-CLI:

wp plugin install https://github.com/dev-alamin/fastcgi-cache-manager/archive/refs/heads/main.zip
No built-in updater. New versions won't appear under Dashboard → Updates. Install new releases yourself, or let Git Updater track the repository.
Readme github.com/dev-alamin/fastcgi-cache-manager ↗

Per-URL Nginx (FastCGI) cache purging and scheduled cache warming for WordPress and WooCommerce — built to be cloned onto any server, not tied to one site's configuration.

Why this exists

Most WordPress-side Nginx cache purge plugins can only do one thing on any trigger: delete the entire cache directory and rebuild it from scratch. That is fine for a low-traffic blog. It is actively harmful on a WooCommerce store, where a single checkout can fire several stock/order hooks in one request — and on a busy store, that means the entire site's cache is destroyed continuously, all day, from ordinary customer traffic. See docs/ARCHITECTURE.md for the full reasoning.

FastCGI Cache Manager purges only the URL that actually changed, whenever it can, and only falls back to a full purge where there's genuinely no safe alternative (e.g. a global Elementor template, a Customizer save).

Three purge strategies

Strategy Needs Purges
Direct (recommended) Your existing fastcgi_cache_key + levels values One exact file, no server config changes
Loopback An nginx purge module or PURGE-method location block One exact file, via an HTTP request
Filesystem Nothing beyond a readable/writable cache path The entire cache (fallback tier)

Direct is the default and the one most sites should use — it needs no nginx module and no new location block, because it recomputes the same cache-key hash nginx already computes, using values already present in your vhost config. See docs/NGINX-SETUP.md for how to find them.

Features

  • Per-URL purge on WooCommerce stock changes, order status changes, Elementor document saves, and any published post/page save
  • Full purge on Customizer saves and global Elementor template changes (nothing narrower is safe for either)
  • Deferred purge/warm execution on shutdown (after fastcgi_finish_request() where available) — purge network calls never add latency to the request that triggered them
  • Scheduled cache warming via WP-Cron, every N hours (default 4), with three discovery methods (sitemap, direct post/page crawl, manual URL list) — see docs/WARMING.md
  • Admin-bar "Purge Cache" button for the current page
  • Settings page with a self-test button, manual purge/warm buttons, and a recent-activity log

Documentation

Requirements

  • WordPress 5.5+ (for the native wp-sitemap.xml fallback; earlier versions work fine with a sitemap plugin or the manual URL list)
  • PHP 7.4+
  • Nginx with fastcgi_cache (or proxy_cache) configured
  • Direct strategy: read/write filesystem access to the cache directory from PHP
  • Loopback strategy: an nginx purge module or location block (see docs/NGINX-SETUP.md)

License

GPL-2.0-or-later — see LICENSE.