Throwing pages away

Change a post and the plugin purges that post, the front page, its categories and tags, its author archive, its date archives, the post-type archive and the feeds. Not the whole cache. Every copy of each page goes — the mobile one, each currency or language a visitor's cookie asked for, and every later or sorted page of a list: clearing the shop clears /shop/page/2/ and /shop/?orderby=price with it, and clearing a post clears its later pages of comments. Up to 500 such pages are kept for each list; beyond that a new one is built for the visitor and not stored. With plain permalinks (?p=123), where every page is an address with a query, pages are not grouped under lists and each is cleared on its own, as before.

Some pages list posts in a way the plugin cannot work out from the post: a news page built with a Query Loop block, a "New arrivals" page, a section of products on a landing page. Put their addresses in Settings → Clearing → Also clear these pages, one per line, copied from the browser or typed as a path such as /news/. Whenever a post, page or product is published, edited or taken down, and whenever a category or tag is added, renamed or deleted, those pages are cleared too, with their later and sorted pages, and passed on to the cache in front like every other page cleared here. Approving a comment does not clear them. When you save, an address on another site, the front page (it has its own switch, Also clear the front page) and a line with * are left out, and the screen lists each one with the reason. Another site can share your site's address: on a site installed in a folder, a whole address outside that folder is another site's, and on a network of sites in folders a page under another site's folder is that site's, whether you paste it or, on the main site, type it as a path. Both are left out as not on this site; list them on the site they belong to. An address in another alphabet can be pasted as the browser copies it (/%D0%BD%D0%BE.../) or typed in its own letters. List only pages that show lists of posts or products: each one is rebuilt after every change. The list is empty until you fill it.

Some changes touch every page, and those empty the whole cache: switching the theme, saving a menu, a widget or the Customizer, and saving a template, a template part, the navigation, the styles or a synced pattern in the Site Editor. So does an update to an active plugin, the theme in use or WordPress itself, and Elementor or Autoptimize clearing the CSS and JavaScript files they generate, since a cached page would otherwise link to files that no longer exist.

Taking a post down — back to draft, or into the Trash — clears the address it was published at, and so does changing its slug. That happens even with Clear when a post is published or edited unticked, because a withdrawn page must not go on being served. With it unticked, publishing and editing leave the cache alone and the page lifetime decides.

That distinction is the difference between a cache that stays warm and one that never does. A site that clears everything whenever a comment is approved is a site paying for a full rebuild several times a day.

You can purge by hand from the toolbar — Cache → Clear the whole cache, or Clear this page while looking at it, which is what you want nine times out of ten. The Dashboard has a Clear the whole cache button too, which does the same. The page reloads with a message under the toolbar saying what happened, including when there was no cached copy to clear. The toolbar item shows on a phone too, as an icon; its dot is filled when caching is on and a ring when it is off, and the menu says which in words. In the admin, Clear cache under any published post, page or product in its list does the same for that page and the pages listing it, without opening it.

Emptying the cache is instant however big it is: the pages are moved aside at once and deleted in the background, a little at a time.

What cleared the whole cache, and who#

A cache that keeps going cold is nearly always something clearing it. The Dashboard's Clearing Log panel lists the last 30 times the whole cache was cleared from this site, newest first: when (in your site's date and time format), why, who was signed in when it happened, and how many pages were removed. Above the list it says how many times that happened in the last 24 hours. Who was signed in is not always who caused it: a plugin that clears the cache when an administrator saves its settings is listed with that administrator, and so is another plugin's background work that runs as the administrator who started it. Only someone who works on the site (a user who can edit posts, such as an author, an editor, a shop manager or an administrator) is named. A clear that happens while a customer or subscriber is signed in is listed with nobody. So is one made by a WordPress scheduled task, or by a job Action Scheduler runs (the queue WooCommerce and many other plugins use for work done in the background), even when an administrator's visit to wp-admin is what set it running. A WooCommerce sale starting on its date clears only that product's pages, which is not a whole-cache clear and is not listed; when another plugin empties the whole cache for it (Countdown Timer does when it counts down to that sale), that entry names nobody. That is asked again each time the log is shown, so a user who has since been deleted or can no longer edit posts is no longer named on older entries either. Entries kept by versions 1.4.0 to 1.4.2 do not record whether a background job made them (1.4.0 and 1.4.1 put a job's clear down to the administrator whose visit ran it), so one whose reasons are all ones a job can give (the words of the code that asked, a Probably, code that could not be named, or Elementor or Autoptimize rebuilding their files) names nobody. That includes such an entry that really was a person's, for example another plugin clearing the cache when an administrator saved its settings. One for something a person does, such as Clear the whole cache, a menu saved or a plugin updated, keeps its name.

The reasons it gives:

• Clear the whole cache button, for Clear the whole cache on the Dashboard or in the toolbar, with the person who pressed it.
• Rules saved, because pages cached under the old rules are cleared.
• Settings imported, for the same reason, when a settings file is imported on the Settings screen.
• The wp nimblecache purge command.
• Theme switched, Customizer saved, Menu saved, Widgets saved, Permalinks changed, and Site Editor: with what was changed (a template, a template part, the styles, a navigation menu or a synced pattern).
• Plugin activated: or Plugin deactivated: with the plugin's name, and Plugin updated:, Theme updated: or WordPress updated for updates. An update of more than three plugins at once names three and says how many more.
• Elementor rebuilt its files and Autoptimize cleared its cache.
• For another plugin or theme that asks through the trnc_purge_all hook: the words it passes, if it passes any, or else Probably and the name of the plugin or theme whose code made the request. That name is read from where the request came from, so it is a good guess rather than a certainty, and the panel says "probably".

When the cache was cleared more than 10 times in 24 hours, a note names the reason seen most and says what to do about it. For a plugin that clears it every time its settings are saved, that is asking its author to clear only the pages it changes. When the code that asked could not be named, it suggests deactivating plugins one at a time to find it.

Several clears in one request within a minute, such as a theme switch that also saves its menus, are one entry. A long-running process (a WP-CLI script, or a cron run with several jobs waiting) that clears it again later in the same run makes a new entry. On a network, an update or a plugin switched on for every site clears every site's cache at once; that is one entry, on the site it was done from, saying Every site of the network, and the number of pages is not counted. Each site keeps its own log, so the other sites of the network do not list that clear.

What is kept: the time, the reason, the user ID of whoever was signed in when that is someone who can edit posts, and the number of pages. Nothing about visitors, customers or subscribers, and nothing is written on a cache hit. Deleting the plugin with Delete all data on uninstall ticked removes the log with the other statistics, on every site. Clearing a single page (a post saved, Clear this page) is not listed: only clears of the whole cache are.