v1.2.4

Fixed: purging did nothing when you were signed in on a preview address

Hostney serves a site on whichever address you reach it by — its own domain, the
www form, or the temporary .hostney.app preview address. WordPress is told
the site address once per request, so it reports back whichever one you happen
to be using.

The plugin took that at face value and sent its cache purge to the address you
were browsing rather than to the site. Preview addresses do not use the page
cache, so there was nothing there to purge: the request failed, and the live
domain's cache was never cleared.

The only symptom is edits not appearing. Nothing is written to any error log,
and the site itself looks perfectly healthy — which is what made this worth
fixing over a version of its own.

Purges are now always addressed to the site's own domain, whichever address you
are signed in on. The URLs sent with them are rewritten to match, because the
purge endpoint rejects any URL that does not belong to the domain asking.

Who this affected: anyone administering a live site over its preview
address, which is common after a migration — the preview URL is usually the one
still in your bookmarks. If you only ever use the site's own domain, purging
already worked and nothing changes for you.

Two things the same change fixes

• Pre-fetch warms the live cache. "Flush and pre-fetch" was warming whichever
  address you were on. On a preview address that meant carefully filling a cache
  nobody reads from.
• The plugin page describes the live site. Page caching, the purge endpoint
  check and the "Detected website" row now all refer to the site's own domain,
  so what the page reports and what its buttons act on can no longer disagree.

Requirements

This relies on a small platform helper that Hostney installs on your site
automatically. There is nothing to configure and nothing to wait for.

Until that helper arrives, the plugin behaves exactly as it did in 1.2.3 —
correct on the site's own domain, unchanged everywhere else.