A screen that reports rather than asks. It names what it found on your site — WooCommerce, Easy Digital Downloads, WPML, Polylang, TranslatePress — and lists exactly what it does about each one. Almost none of it is a setting, because a cart page is not cacheable in a way anybody could have an opinion about. The one switch is Also clear the cache in front, below.

It is there because the work is invisible. All of it happens whether or not anybody reads the screen, and a merchant who cannot see it has to take on trust that their checkout is safe.

With Easy Digital Downloads, the downloads in an order are cleared when it completes, is refunded or is revoked. With WPML or Polylang giving each language a domain or subdomain of its own, each domain keeps its own cached pages, and a request for a domain the site does not use is never cached. Where Polylang has the language in the address, its language cookie no longer splits every page in two, except for the front page when Polylang sends visitors to their browser's language.

The same screen shows the two ways any plugin can keep itself out of the cache: the DONOTCACHEPAGE constant every caching plugin honours, and the trnc_bypass filter, which can also say why — and what it says appears in Diagnostics.

The cache in front#

Many hosts keep a page cache of their own in front of WordPress (Varnish, nginx, LiteSpeed), and Cloudflare with APO or a Cache Everything rule does the same further out. That cache keeps its own copy of a page, so clearing NimbleCache's copy alone can leave visitors seeing the old one.

Where that cache can be told from inside WordPress, NimbleCache tells it. Every page NimbleCache clears, whether by a post edit, a stock change, Clear this page in the toolbar or Clear cache in a list, is passed on to:

Cloudflare, through Cloudflare's own plugin. That plugin clears a page only with APO on, or with its automatic cache management on and a Cache Everything page rule. It reads page rules, not Cache Rules, so a zone that keeps pages through Cache Rules without APO gets nothing from it, and the answer says so;
Nginx Helper, while its Enable Purge is on;
Proxy Cache Purge (Varnish);
SiteGround Speed Optimizer, while its dynamic or file cache is on. The front page is cleared on its own, never with every page below it;
Breeze, while its Varnish cache is on (Cloudways);
LiteSpeed Cache. It clears through the answer to the request that asks it, so when that answer has already gone it keeps the purge and sends it with the next request WordPress answers. From LiteSpeed Cache 4.4.2 it is asked without its own "Purge url" notice for every page; older copies still show one for each page cleared. Clear the whole cache asks it to empty its pages only: its CSS and JS files, its object cache, PHP's code cache and Cloudflare are left alone, as they were before you pressed it. LiteSpeed Cache's own Purge All still empties all of those;
Kinsta's own cache, on Kinsta;
WP Engine, for posts and pages. A list such as the front page cannot be cleared there on its own, so Clear the whole cache is what reaches it.

The other cache is cleared whole only when you press Clear the whole cache, in the toolbar or on the Dashboard, or run wp nimblecache purge. Behind Cloudflare that also clears the images, scripts and styles Cloudflare holds, and visitors then fetch them from your server again until Cloudflare has them back. The Dashboard's button names the caches it will clear whole when you point at it. When NimbleCache clears everything by itself (a menu saved, a plugin updated, the Rules saved), the other cache is asked instead for the pages NimbleCache held, the front page first, up to 50 of them. Other pages there are refreshed when their own lifetime there runs out.

This happens at the end of the request. Where PHP runs through PHP-FPM or LiteSpeed, your browser has its answer before then, so saving a post does not wait for it; elsewhere it waits. When a visitor's request cleared the page (an order changing a product's stock), it is handed to WordPress's scheduled tasks and sent about 20 seconds later, the next time those tasks run, so a customer's checkout never waits for it. On a site that runs its scheduled tasks from the server's own schedule rather than from visits, that is at the next run.

Clear this page, Clear cache and Clear the whole cache ask straight away, so their answer can say what happened: "Cloudflare was also asked to clear its copy". Most of these caches do not report back whether a clear worked, so "asked" is often all NimbleCache can say. It does watch the requests the other plugin makes while it is asked: one that fails or is refused makes the answer say that cache could not be reached or answered with an error, and so does an error the plugin raises or reports (Breeze reports one, and SiteGround does for its dynamic cache). Kinsta's clear is sent without waiting for its answer, and LiteSpeed Cache, WP Engine, and Nginx Helper when it deletes its own files, clear without a request to watch, so for those "asked" is the whole story. After a change nothing answers directly, such as a post saved, a cache that could not be reached is said once on the next admin screen opened by whoever made the change, when they can edit posts: an editor or a shop manager as well as an administrator. A change made by someone who cannot edit posts, a customer's order for instance, is sent by the scheduled task described above, and nobody is told. On a network, these answers and notes are said on the site where the change was made, never on the next site you open. The Clearing Log says the same about each whole clear. A cache that refuses or fails never turns a save into an error.

Asking has a time limit: 8 seconds in a request somebody may be waiting for, 20 in a scheduled task or WP-CLI. Each request to the other cache waits at most what is left of that time, and a second at least, so a plugin that makes several requests in one go (Cloudflare's does) can take a few seconds more. Once the time has run out the rest are not asked, and the answer says so. At most 200 addresses are passed on for one request.

The Cache in Front panel on the Integrations screen lists which are active and what is done about each, and says so when one clears nothing, with why and what to do: Enable Purge off in Nginx Helper, or Cloudflare's plugin without APO, for example. It also shows what the last Diagnostics check saw in front of the site that NimbleCache cannot clear and what to do about it, when your host's own page cache answers before NimbleCache is reached (in which case one of the two caches is enough), and when the last one asked could not be reached. For a host's cache, that is to clear it in the host's control panel; for CloudFront, to create an invalidation in your AWS account; for QUIC.cloud, that LiteSpeed Cache clears it while active, or to press Purge All CDN Cache on your QUIC.cloud dashboard. The Dashboard shows a warning when the last check heard a cache answer that nothing is clearing. The panel and the warning read that check afresh each time they are opened, the headers it quoted included, so when an update changes what NimbleCache knows about a cache, the warning can appear, or go, and the advice change, without a new check. A header that check did not keep is read only by a new check. Also clear the cache in front is on for every site and can be switched off there.