LynBro Plugins
/ Cache
LynBro Plugins
/ Cache
Most cache plugins tell you they cleared something. This one tells you what it cleared, why each address was on the list, and what became of it — and when it could not clear something, it says that instead of reporting success.
Free, completely, forever. There is no paid tier and none is planned: it runs entirely on your own server and contacts no external service.
calls to FLUSHDB. A flush moves a generation number on instead, so a second site, a queue or a session store sharing that Redis is left alone.
nginx writes the cache key it used in plain text inside every cache file. So this plugin does not compute a filename and hope: it opens the file, reads the key nginx put there, and removes it only when that key is the one it meant to remove. If the file holds a different address, nothing is deleted and the journal says so.
The cache directory, the levels layout and the fastcgi_cache_key are established by reading real cache files on your server and reproducing their keys exactly. The diagnostics screen says how many files a setting was confirmed against — and says “not confirmed” rather than filling in a plausible guess.
No minification, no critical CSS, no deferred JavaScript, no CDN rewriting. Those are the features that break sites, they are well covered elsewhere, and a tool that clears caches reliably is more useful than another tool that does everything unreliably.
No "Pro" tier, no nag screens. The features other plugins paywall are here from day one.
$scheme is part of the key on most configurations, so the same page is cached twice. Clearing one and leaving the other is the commonest reason a purge appears to do nothing — both are cleared.
With $request_method in the key, GET and HEAD are separate entries, and both are cleared.
nginx is normally told to cache 301 responses too, so the same address with the trailing slash the other way round holds a cached redirect. It is cleared with the page, so visitors do not land on the old one.
One cache directory often holds every site on the machine. The key of each file is read, only the entries belonging to your own hostnames are removed, and you are told how many were left alone.
The log-in screen, cron, the WooCommerce basket, checkout and account pages (found from your actual pages, not from English slugs). It sends X-Accel-Expires, which survives a common nginx setting that ignores Cache-Control, then requests each address twice to prove it worked.
If Redis is unreachable, the bundled drop-in finishes the request from an ordinary in-memory array — exactly as WordPress behaves with no object cache — and records the reason where the diagnostics screen shows it.
“Cleared 14 addresses because a post was updated” — open the row to see all fourteen, why each was on the list and what happened to it: removed, was not cached, left alone.
Static CSS, JavaScript, fonts and images get a one-year lifetime from a marked .htaccess block. HTML and service workers are left alone.
Token endpoints from other LynBro plugins are protected from the start, you can add your own addresses, and any plugin can register its own through a filter.
Open Diagnostics and look at “The cache key”. If it says the key is not confirmed, the template in Settings does not match the fastcgi_cache_key line in your nginx configuration, so the filename being computed does not exist. Copy the real line into Settings; the plugin will confirm it against your cache files and tell you it agrees.
That happens when nginx and PHP-FPM run as different accounts. The plugin switches to asking nginx through its purge location instead, and the journal then says “nginx asked to drop it” rather than “removed” — because from PHP’s side that is all it can honestly claim.
No. Only entries whose stored key contains one of your own hostnames are removed, and the confirmation dialogue tells you the count and the size first.
It clears what is on your server. A CDN keeps its own copy and needs its own purge; this plugin does not pretend otherwise.
No. The object cache half works on its own, and so does the protection for addresses that must never be cached.
No. It is a separate button and the page-cache side is unaffected either way. If another plugin already owns object-cache.php, this plugin leaves that file exactly where it is.
No, and none is planned. The plugin runs entirely on your own server and costs us nothing per site.