v1.2.1

WordPress plugin for automatic cache management on Hostney hosting.

Object caching now works with Redis as well as Memcached, and the site works out which one it is on by itself.

This release also contains v1.1.0 and v1.2.0, neither of which was published here. Upgrading from v1.0.0 gets you all three.

What's new

Redis object caching

The object cache drop-in speaks to Redis or Memcached. Which one it uses is decided per request, by probing for each engine's socket and connecting to whichever answers.

That is the whole mechanism, and it is why switching engines in the Hostney control panel needs no action on the site: the panel stops one engine and starts the other, and the next PHP request finds the new socket and connects to it. Nothing to reconfigure, no file to edit, no constant to set.

The drop-in now looks after itself

Three things that all used to need a human:

• Activating the plugin installs the drop-in, if nothing else already owns the object-cache.php slot. Deactivating has always removed it, so until now the plugin could take the file away but never put it back - the only thing that created one was a button on the admin page.
• Updating the plugin updates the drop-in. A plugin update does not normally touch wp-content/, so a site upgraded from v1.1.0 kept a Memcached-only drop-in. It carried on working on Memcached and would have quietly stopped caching if the account switched to Redis. The drop-in is now stamped with the plugin version and rewritten when it is stale.
• The admin page tells you when the drop-in is out of date, instead of reporting it as current.

A drop-in belonging to another plugin is never touched, with or without these changes.

A cache that cannot take the site down

If neither engine answers, the drop-in falls back to a non-persistent in-memory array for that request. The site keeps serving; it just stops caching between requests until the socket is back.

A socket that accepts a connection is not a server that answers, so the drop-in checks for a real response rather than trusting the connect, and it uses a short timeout throughout - both engines are on the same machine, so a slow one is a broken one.

Fixed: wp_cache_supports( 'flush_group' ) now reports false

It reported true while only clearing the in-process array. That told WordPress a group flush had invalidated persistent entries when it had not, so anything relying on wp_cache_flush_group() could read stale data back out of the object cache. Reporting false makes WordPress fall back to a path that actually works.

Features

• Automatic nginx cache purge on content changes - posts, pages, custom post types, taxonomies, comments
• Smart URL collection - purges permalink, homepage, RSS feed, sitemap, and related archives
• Deduplication and batching - multiple changes in a single request are collected and deduplicated
• Batch overflow protection - falls back to full cache clear when more than 15 URLs are queued
• Gutenberg debounce - handles concurrent save requests without duplicate purges
• Redis or Memcached object cache management, detected at runtime
• Admin page with status overview, manual purge button, and activity log
• Admin bar and post editor purge buttons

Requirements

• WordPress 5.0+ (tested to 6.9)
• PHP 7.4+
• Hostney hosting (nginx caching with OpenResty/Lua)
• For object caching: the redis or memcached PHP extension, whichever engine the account runs. Both ship in the Hostney PHP images.

Upgrading

No action needed. Sites hosted on Hostney get the update automatically, and the drop-in is installed or refreshed on its own.

If the admin page reports the drop-in as out of date after an update, wp-content/ is not writable - fix the permissions, or use the Update drop-in button once the directory is writable again.