Zinn® Cache
| 开发者 | zinndigital |
|---|---|
| 更新时间 | 2026年10月26日 03:33 |
| PHP版本: | 8.2 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
标签
下载
详情介绍:
Zinn® Cache makes a WordPress site faster wherever it is hosted. On a LiteSpeed server it drives the server's own page cache. When nginx, Varnish or Apache already caches pages in front of WordPress, it does not add a second page cache behind them: it tells them which pages changed. On any other server it stores each page as a file and serves it before WordPress loads. It also installs a Redis object cache that proves it is working, and purges only the pages a change affects.
It is installed for you on sites hosted with Zinn Digital®, and it works the same way on any other host. There is one Zinn® cache plugin; Zinn® Cache Pro is an optional add-on that installs on top of it (see Pro features below).
What it does
- Page cache on any server. On a LiteSpeed server it stamps
X-LiteSpeed-Cache-ControlandX-LiteSpeed-Tagheaders so the web server serves full pages without hitting PHP or MySQL. On any other server it stores each complete page as a file underwp-content/cache/zinn-cache/and serves it fromadvanced-cache.phpbefore WordPress loads (it addsdefine( 'WP_CACHE', true );towp-config.phpfor that, and removes it again when the page cache is turned off). Only visitors who are not signed in are served stored pages, and only addresses with no query string (tracking parameters such asutm_sourceare ignored). If the third-party LiteSpeed Cache plugin is present, page caching is deferred to it instead. - Smart auto-purge. When content changes — a post or page is saved, trashed or deleted, a comment is added or moderated, a taxonomy term is edited — only the affected pages (and the listings they appear on: its home page, archive, categories, tags and author page) are purged, on every cache layer: LiteSpeed by cache tag, the disk cache, nginx, Varnish, Apache and Cloudflare by address. A change that touches every page (the theme, a plugin, an update, a menu, the site title) starts the paced refresh described below. The plugin can also mirror each purge to a control panel over a signed webhook, but only when
ZINN_CACHE_PANEL_URLis defined — and the Zinn Digital® platform does not set it today, so on a Zinn-hosted site purges happen on the server and are not mirrored anywhere. - Redis object cache. A one-click toggle installs a self-contained Redis object-cache drop-in (requires the phpredis extension), offloading repeated database reads. It signs in with a plain password or a Redis 6+ ACL username and password, honours the usual
WP_REDIS_*constants (includingWP_REDIS_PASSWORDgiven asarray( 'user', 'password' ),WP_REDIS_PATHandWP_REDIS_MAXTTL), and proves itself with a write-and-read round trip: if Redis refuses the login or the data, the settings screen says why instead of showing a cache that stores nothing. The plugin never overwrites another caching plugin's drop-in, refreshes its own drop-in after an update, and the drop-in falls back to an in-memory cache if Redis is unreachable, so the site keeps working. Choose the igbinary serializer (smaller and faster, when the extension is installed) or PHP's own; each stored value is read in the format it was written in, so switching is safe at any time. - Host-managed object cache. A host that installs this drop-in for its customers (as Zinn Digital® hosting does) defines
ZINN_CACHE_MANAGED_OBJECT_CACHE; the plugin then never removes that drop-in and shows the cache as managed. A host whose Redis users may not runSCANcan defineZINN_CACHE_FLUSH_SOCKET, the path of a local helper that deletes only the calling site's keys, so "Flush cache" keeps working. - Server caches in front of WordPress: nginx, Varnish, Apache. Zinn® Cache detects an nginx
proxy_cache/fastcgi_cache, Varnish, Apachemod_cacheor LiteSpeed in front of the site from the response headers, and then keeps its own disk cache out of the way. Tell it how to reach the cache and it purges changed pages there: nginx by a purge request (thengx_cache_purgemodule), by deleting the cache files when WordPress can read the cache folder, or by writing the changed addresses to a folder your host's purger reads; Varnish byPURGEorBAN; Apache's disk cache by deleting the entry files. Signed-in visitors, excluded addresses and form posts are sentCache-Control: private, no-store, so a server cache never keeps one person's page for the next. - Cloudflare purge. With a zone ID and an API token limited to Cache Purge, changed pages are purged from Cloudflare's edge by address, in batches, from WP-Cron so editors never wait on it. Emptying the whole zone is off unless you allow it.
- Paced refresh instead of "purge everything". An update, a plugin activation, a theme or menu change or a site-wide setting no longer empties the cache at once — that sends every visitor to WordPress in the same minute. Zinn® Cache refreshes the site a batch a minute instead (100 pages by default), newest first, all the way to the end, and pauses while the server is busy. "Empty all now" is still there for the rare time you want exactly that.
- Status screen and per-address purge. One screen says what serves your pages (LiteSpeed, nginx, Varnish, Apache, Cloudflare or the disk cache), what the last check saw in front of the site, how big each cache is where WordPress can read it (and says plainly when it cannot), the purge queue, the paced refresh and the last purges with what each layer answered. Purge any address from there, check the hit ratio on a sample of pages, or start and stop a refresh.
- Lighter pages. Control the WordPress Heartbeat, show text at once while Google Fonts load (
display=swap), connect early to the servers your pages use, and serve images, CSS, JavaScript and fonts from a pull CDN address. - Safe cache exclusions. Ships with sensible WordPress and WooCommerce/Easy Digital Downloads defaults — cart, checkout, my-account, REST/AJAX, preview, search, and any logged-in or session-cookie request are never cached. Extra path, query-key, and cookie-prefix rules can be added per site.
POST /wp-json/zinn-cache/v1/purge, purges everything, specific URLs, or specific tags. It accepts a logged-in administrator, or any caller holding the site's ZINN_CACHE_PANEL_SECRET who signs the request body with it (HMAC-SHA256) — so a deploy script or your own tooling can clear the cache. Your Zinn® dashboard does not call it today; there is no dashboard purge button for this plugin yet.
Pro features
Everything above is free and stays free. Zinn® Cache Pro is an add-on that installs on top of this plugin and adds:
- A cache analytics screen: hit ratio, memory, keys and the slowest cache commands.
- A slow-query and uncached-call finder that names the plugin or theme responsible.
- An in-memory APCu tier in front of Redis for the hottest keys, plus prefetching and compression (zstd, lzf or gzip).
- Tag-based purging for posts, terms and WooCommerce products, so only what changed is cleared, with the page and object caches purged together.
- Automatic cache warm-up after a purge and when a paced refresh finishes, WebP and AVIF images, missing image width and height added from the file, unused-CSS removal and delayed JavaScript.
- Cloudflare's own cache-hit ratio for the last 24 hours on the status screen.
- Scheduled database clean-up with a preview, and per-page cache rules.
- Cache health alerts in your Zinn Digital® dashboard when the hit ratio drops or memory fills.
安装:
- Upload the
zinn-cachefolder to/wp-content/plugins/(this is done automatically as part of the Zinn® deploy footprint). - Activate the plugin through the Plugins screen in WordPress.
- Go to Zinn Digital® → Cache to configure the full-page cache, object cache, auto-purge, and exclusions.
wp-config.php (set automatically on Zinn-hosted sites):
ZINN_CACHE_PANEL_URLandZINN_CACHE_PANEL_SECRET— enable signed purge mirroring to the control plane.WP_REDIS_HOST,WP_REDIS_PORT,WP_REDIS_DATABASE,WP_REDIS_PASSWORD,WP_REDIS_PREFIX— override the object-cache connection.
屏幕截图:
常见问题:
My host runs nginx. How do I set up Zinn® Cache?
Open Zinn Digital® → Cache → Status and press Check now. If nginx caches your pages, the screen says so and Zinn® Cache does not install its own page cache behind it. Then open the Server cache tab, choose nginx, and choose how to purge it: a purge request per page if your nginx has the ngx_cache_purge module (set "Send purges to" to http://127.0.0.1 when a CDN is in front); delete the cache files if WordPress can read the folder in your proxy_cache_path or fastcgi_cache_path line (copy the folder, the levels= value and your cache key); or write the addresses to a folder your host's purger reads. Save, then purge one address from the Status tab and check that its next visit says MISS. If nginx does not cache your pages at all, choose None and Zinn® Cache's own page cache does the job.
Varnish, Apache mod_cache or Cloudflare?
Varnish: choose Varnish, give its address and port, and allow PURGE (or BAN) from this server in your VCL. Apache: put mod_cache in a reverse-proxy virtual host in front of WordPress — inside the same server as WordPress's own rewrite rules, Apache stores every address as /index.php and can serve one page for all of them; the status screen warns when it sees that. Cloudflare: switch on Cloudflare purge and paste a zone ID and a token limited to Cache Purge.
Why does an update no longer empty the cache?
Because emptying it sends every visitor and every crawler to WordPress in the same minute, and on a large site that can take the server down. Updates, plugin activations, theme and menu changes start a paced refresh: every page is refreshed, a batch a minute, newest first, until the whole site is done, and the refresh pauses while the server is busy. Empty all now on the settings screen empties everything at once when you want that.
Why is there no "combine CSS/JS", "minify" or "separate mobile cache" option?
On purpose. Combining files was a workaround for HTTP/1.1; on HTTP/2 and HTTP/3 it makes pages slower to start and breaks caching of shared files, which is why other cache plugins have been retiring it. Minifying saves a few percent once files are compressed (gzip or Brotli) and is the most common cause of a broken layout after installing a cache plugin. A separate mobile cache doubles every cached page and every server-cache key for themes that are responsive anyway; Zinn® Cache Pro's warm-up can warm a mobile pass for the few sites that do serve phones a different page.
Does this require LiteSpeed?
Full-page caching requires a LiteSpeed web server (or the third-party LiteSpeed Cache plugin). On any other server nothing reads the cache headers, so pages are not cached — and the settings screen says so plainly rather than looking as if it works. Everything else (object cache, exclusions, and the signed purge endpoint) still works.
Does it conflict with the LiteSpeed Cache plugin?
No. If the LiteSpeed Cache plugin is active, Zinn® Cache defers page caching to it and routes purges through its public actions.
What happens if Redis is unavailable?
The object cache is optional. If the phpredis extension is missing the toggle is disabled with a notice; if Redis becomes unreachable at runtime, the drop-in serves from a per-request in-memory cache so the site never breaks.
How do I clear the cache from the command line?
With WP-CLI: wp zinn-cache purge all empties every cached page, wp zinn-cache purge url https://example.com/pricing/ (or just /pricing/) empties those pages, and wp zinn-cache purge post 42 empties a post's page and the lists it appears on. Each prints how many stored pages it removed. On a LiteSpeed server the purge is sent to the server with the next request, which the command makes itself.
更新日志:
1.11.1
- Security: the AI-app sign-in's "Disconnect" action now checks the signed-in user's capability as well as the nonce (WordPress.org review standards).
- Updates no longer empty the cache. For every site: a WordPress, plugin or theme update, a plugin activation or deactivation, a theme switch, a menu save and a site-wide setting now start a paced refresh (100 pages a minute by default, paused while the server is busy) instead of purging everything at once. Empty all now (formerly "Purge everything now") still empties the cache at once.
- New: server caches in front of WordPress. nginx (purge request, cache files, or a spool folder for the host's purger), Varnish (PURGE or BAN) and Apache mod_cache are purged when content changes, and Zinn® Cache no longer installs its own page cache behind one. Sites with no server cache keep the disk page cache exactly as before.
- New: Cloudflare purge by address (batched, from WP-Cron), with emptying the zone off unless allowed.
- New: Status tab — what serves your pages, what is in front of the site, cache sizes, the purge queue and log, a hit-ratio check, per-address purge and the paced refresh.
- New: serializer setting for the Redis object cache (igbinary or PHP). The drop-in (revision 4) reads each value in the format it was written in, so a server that gains or loses igbinary no longer misreads stored values.
- New: Heartbeat control, Google Fonts
display=swap, early connections (preconnect) and a CDN address for static files. - New: WP-CLI
wp zinn-cache server detect,wp zinn-cache server drainandwp zinn-cache refresh start|stop|status|tick;purge urlreports what each cache layer answered. REST routes and AI-agent (MCP) tools for the status, per-address purge, detection and the refresh. - A purge by address now reaches a LiteSpeed server too (it used to purge only by tag there).
- WordPress MCP adapter updated to 0.7.1 (MCP protocol 2026-07-28, session-storage security fix); no deprecation notice from the bundled copy.
- Plural forms in every language now follow that language's own plural rules (Russian, Polish, Czech, Croatian, Serbian, Arabic, Hebrew, French and others), re-filled by the translator with a human check on the forms it could not tell apart.
- AI agents (MCP): this plugin's tools now always appear to your AI app, even when another Zinn® plugin on the same site is an older version.
- More dependable AI app sign-in (MCP): Claude, ChatGPT and other AI apps connect to your site the same way whether a visitor, a scheduled task or a WP-CLI command started WordPress.
- Faster and lighter on servers: WP-CLI commands, scheduled tasks and AI agents (MCP) on your site now start with less memory, so they keep working beside large plugins such as WooCommerce.
- Translation template refreshed so every language stays complete.
- AI agent (MCP) tools load faster and use less memory.
- The MCP connection's sign-in response no longer switches off JSON escaping.
- Lighter start for WP-CLI commands: works within a 128 MB memory limit beside WooCommerce and other large plugins.
- Fixes a site build failure: Zinn® Cache no longer stops WordPress from loading if one of its files is missing.
- New: a title, description, redirect or site-wide setting changed in Zinn® SEO reaches visitors straight away: exactly the pages it changed leave the cache, and a bulk change is one purge.
- Packaging only, no behaviour change: the licensing icon is now shipped as assets/images/sdk-icon.png instead of a file named like a WordPress.org directory asset (WordPress.org review guidance).
- The Zinn® panel now appears only on this plugin's own screens, never on the WordPress dashboard (WordPress.org guideline 11).
- Updated Freemius SDK to the latest version.
- The readme's External services section now lists the request made when an AI app signs in to the site's MCP server (its public OAuth client metadata); no behaviour change.
- Security-scan annotation on the AI agents (MCP) sign-in screen (no behaviour change): every value on its Allow button is escaped.
- New:
wp zinn-cache purge all|url|post, so a stale page can be cleared from the command line. Fixed: "Purge everything now" and the zinn_cache_purge_all action did nothing; a purge from WP-CLI on a LiteSpeed server is now sent with the next request instead of being dropped.
- Saving a draft, pending or scheduled post no longer empties the cache of your home page and archives; unpublishing a post still clears its pages.
- AI apps (Claude, ChatGPT) can now sign in with OAuth on a site where this is the only Zinn® plugin with an AI-agent server; the sign-in did not start there.
- MCP tools for AI connector directories: tool descriptions state only what each tool does (no references to other tools); every tool that takes input declares it; list results reach MCP clients as objects.
- Serbian: quotation marks are now „…“ throughout, as the Serbian WordPress translation team writes them.
- Translations follow each language's WordPress.org translation team style guide: its quotation marks, spacing before punctuation, apostrophes and ellipsis, and the forms of address it uses.
- Ukrainian: a site's visitors are now «відвідувачі» everywhere; some screens called them «користувачі» (users).
- Japanese follows the WordPress.org Japanese team's style guide: a half-width space around Latin text, half-width colons and question marks.
- New: two wp-config.php switches for the Zinn Digital® panel. define( 'ZINN_CACHE_PROMO', false ); removes the panel (dashboard widget, settings block and footer), and define( 'ZINN_CACHE_PROMO_HOSTING_URL', 'https://…' ); points its hosting offer at another https address.
- Security: the AI-app sign-in (MCP OAuth) checks a client's metadata address more strictly before fetching it (a public web address only, a limit per address, and a refused address remembered).
- AI apps such as Claude and ChatGPT can connect by signing in (OAuth 2.1) — no application password needed; every MCP tool declares whether it is read-only or destructive.
- Every bundled translation is redone with the current Google model: each locale in its own script (Serbian in Cyrillic), in the register its WordPress translation team uses, with the original spacing, placeholders and entities preserved.
- New: Zinn® Cache has its own icon on WordPress.org, on the licensing screens and on zinndigital.com, in place of the generic Zinn® letter.
- On sites hosted by Zinn Digital®, this plugin is now installed from WordPress.org, so it updates from WordPress.org like any directory plugin. No change to what it does.
- Fix: with WooCommerce active, every WP-CLI command (for example
wp option get) used about 6 MB more memory than before the AI agents (MCP) release, which could push a site over a 128M limit. The site's MCP server now starts only forwp mcp-adapterand on web requests; defineZINN_MCP_DISABLEDin wp-config.php to turn every Zinn® MCP server off.
- AI agents (MCP) and REST: read the cache status, purge, change every setting and read the diagnostics from AI apps, with your WordPress permissions (administrators). On by default; switch under Cache → AI agents (MCP).
- Hardened: the page cache refuses a request whose Host header is only dots, so a stored page is only ever read from, or written to, that host's own folder. No stored page could be reached this way before; the request is now refused on its shape.
- Readme: the WordPress.org edition keeps its disclosure of the hosting-customer discount request, and says plainly that the card never contacts the platform's update address.
- New: on a site hosted by Zinn Digital®, the settings screen offers hosting customers a personal discount code for their first payment of Zinn® Cache Pro. It is not shown once Pro is active, or on any site Zinn Digital® does not host.
- Fixed: this plugin's .htaccess rules are written above WordPress's own rewrite rules, where they take effect on every page (before, a block could land below WordPress's catch-all and only apply to the home page); a block written below them earlier is moved on the next admin page load.
- Freemius's own packages now match ours byte for byte: the upload that failed on 2026-09-29 is fixed, and nothing else changes.
- Never stops the site if the bundled Freemius SDK is missing: the cache keeps working without it, and
wp zinn-cache statusreports freemius=false.
- New: a page cache for servers that are not LiteSpeed. Each page is stored as a file and served before WordPress loads; purges clear exactly the pages a change affects.
- The object-cache drop-in (revision 3) lets Zinn® Cache Pro add its features without replacing it.
- Smaller download: the editable translation sources (.po) are no longer shipped; WordPress only ever loads the compiled .mo and .l10n.php files, which are unchanged.
- Updates install whenever you click Update, even months later: the download link is fetched fresh at install time instead of expiring in WordPress's saved update data.
- New
wp zinn-cache status --format=jsonreports whether the object cache is really storing data (connected), or has silently fallen back to memory (fallback) and why (last_error), with the Redis server's hit ratio; the last result is kept in thezinn_cache_object_cache_statustransient. - With the page cache switched off, the plugin no longer writes an empty block into .htaccess, and removes one left by an earlier version.
- The object-cache drop-in is loaded by WordPress on whatever PHP the site runs, so it no longer uses any PHP 8-only function: it runs on PHP 7.4 and later. The plugin itself still requires PHP 8.2.
- Security hardening: the design-token stylesheet validates every component id and strips anything that could close the inline style.
- The Translations section no longer says the plugin has 56 user-visible strings. The plugin has grown to nearly three times that many, and every one of them is translated; the count was typed by hand and stopped being true as strings were added, so it is gone rather than corrected.
- The plugin's description in your Plugins list no longer offers remote purge from your Zinn® dashboard or one-click admin login. Neither is part of this plugin: one-click login moved out in 1.3.2, and the dashboard does not send purges to it. It now names what the plugin does — smart auto-purge, a signed purge endpoint for your own tools, a Redis object-cache toggle and safe exclusions — in every language it ships.
- The readme no longer describes one-click admin login, which moved out of this plugin in 1.3.2, and the settings are found under Zinn Digital® → Cache. Screenshots added for the WordPress.org listing. Tested up to: 7.1 — the major version, as WordPress.org requires.
- Tested up to WordPress 7.1.1.
- In a right-to-left admin language, the Zinn Digital® menu entry showed its trademark symbol on the wrong side of the name. The name is now isolated so it reads correctly in Arabic, Hebrew, Persian, Pashto and Urdu.
- Number fields on the settings screen are now wide enough to show the whole value. A long value — a page-cache lifetime of 604800 seconds, say — was cut off to its first few digits, so the setting looked wrong even when it was right.
- This readme no longer says cache purges are driven from your Zinn® dashboard. The purge endpoint in the plugin is real and works for an administrator or a caller holding the site's secret, but the platform does not yet send purges to it or receive purge mirrors from it, so the description said more than the product does.
- When somebody's access to a site is revoked in your Zinn® dashboard, the WordPress admin session they already had open now ends on their very next click. Before this release a one-click login that was already open kept working until WordPress ended it on its own — up to 48 hours — so removing a developer, an agency or a former member of staff did not take effect straight away for whoever still had a tab open.
- Only sessions that were opened from your Zinn® dashboard are ended. Your own WordPress logins, and anyone else's, are untouched.
- The admin screens' styles and scripts are now enqueued through WordPress rather than printed into the page, so they can be dequeued, deferred or optimised by your site like any other asset — and they still work on a site whose security policy forbids inline code.
- The page-cache decision no longer leaves an output buffer open for WordPress to unwind at the end of the request; the plugin closes its own and never touches anybody else's.
- One-click login from your Zinn® dashboard now claims its single-use token atomically, so the same token can never be accepted twice even on a site with no object cache.
- Translations: every string this plugin's admin shows is now translated in every bundled language. A few strings the machine translator refused were shipping in English; they are now translated by hand.
- Hardening: a settings rule can no longer be mistaken for a PHP function with the same name. The same shared settings code is what stopped Zinn® Translate saving its settings. Nothing about how this plugin behaves changes.
- Fixed: the plugin told the update service it was version 1.0.0, so a site already on the latest version was offered the same version again on every check and re-installed it.
- Fixed: changing the Site Title, tagline, front-page, permalink, posts-per-page, widget or theme settings, or saving a menu, now purges the whole page cache. Previously every cached page kept the old value until it expired.
- Added the Zinn® panel: links to Zinn Digital® hosting, the Zinn® marketplace, Zinn Hub® and this plugin's user guide, from inside the WordPress admin.
- Initial release: LSCache control, smart tag-based auto-purge, Redis object-cache toggle, safe cache exclusions, and a signed remote-purge REST endpoint.