v1.2.2

Flush and pre-fetch

Purging a cache is instant. Refilling it is not — and until it refills, the next
visitor to every page pays for the render. On a site with a few hundred pages
that is a slow half hour for whoever happens to arrive first, right after you
changed a theme or ran a bulk edit.

Flush and pre-fetch clears the page cache and then requests every public URL
once, so the cache is full again before anyone asks for it. It is on the plugin
page with a progress bar, and in the admin bar menu from anywhere on the site.

It is slow on purpose

A hosting account has a small, fixed number of PHP workers. Warming is by
definition a stream of uncached requests, so every one of them occupies a
worker for a full page render. Fire several at once and the warmer takes the
site down for real visitors while claiming to make it faster.

So: one request at a time, a pause between them, a 500-URL cap, and the work
runs in the background on WP-Cron rather than holding a browser tab open. A few
hundred pages takes tens of minutes. That is the correct speed, not a limitation
to be tuned away.

Batches are time-boxed rather than a fixed URL count. spawn_cron() will not
spawn again inside WP_CRON_LOCK_TIMEOUT, so a tick happens roughly once a
minute however often it is asked — a fixed five-URL batch would have warmed five
URLs a minute, and a 500-page site would have taken a day and a half.

It warms your origin, not a CDN edge

Requests go to 127.0.0.1 with a Host header rather than to the public
hostname. Three reasons, and each one matters on a different kind of site:

• On Hostney, PHP-FPM shares the host network namespace, so 127.0.0.1 really
  is the nginx holding this site's page cache.
• A site behind a CDN would otherwise warm an edge node — possibly without ever
  reaching the origin whose cache was just emptied.
• The request arrives from a private address, so the bot-protection layer passes
  it before any scoring or challenge logic runs. A challenge page written into
  the page cache would then be served to every subsequent visitor.

URLs with a query string are skipped: they bypass the page cache on the default
configuration, so warming one renders a page and stores nothing.

It tells you when there is nothing to warm

If a whole run comes back with no page-cache header on any response, the result
says page caching looks switched off for the site — rather than reporting N
pages warmed into a cache that does not exist. That failure is otherwise only
discovered later, by the site still being slow.

Admin bar

The single "Hostney: Purge cache" item is now a menu: Purge cache, Flush
and pre-fetch, and Cache settings. The parent links to the settings page
rather than being inert, and while a pre-fetch is running its label carries the
progress — so "is it still going?" is answerable without opening the page.

Filters

Filter	Default	Purpose
hostney_cache_warm_max_urls	500	How many URLs a run may queue
hostney_cache_warm_urls	—	The collected URL list, before it is trimmed
hostney_cache_warm_delay_ms	200	Pause between requests
hostney_cache_warm_batch_seconds	20	How long one cron tick may spend warming

Upgrading

Nothing to do. No settings, no migration, and the object cache drop-in is
untouched by this release.

Deactivating the plugin now also clears any queued warm-up, so a run cannot
outlive the plugin and reappear on the next activation.