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
Install
No release zip yet. The repository archive installs, but the folder name will carry the branch suffix and updates will not flow:
wp plugin install https://github.com/dev-alamin/fastcgi-cache-manager/archive/refs/heads/main.zipReadme
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(afterfastcgi_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
- Installation
- Nginx setup — purge module, allow/deny, finding your cache key
- Cache warming — sitemap, crawl, manual, and the cron schedule
- Settings reference
- Architecture — why per-URL purge, and the trade-offs of each strategy
- Troubleshooting
Requirements
- WordPress 5.5+ (for the native
wp-sitemap.xmlfallback; earlier versions work fine with a sitemap plugin or the manual URL list) - PHP 7.4+
- Nginx with
fastcgi_cache(orproxy_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.