Zinn® Cache

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-Control and X-LiteSpeed-Tag headers so the web server serves full pages without hitting PHP or MySQL. On any other server it stores each complete page as a file under wp-content/cache/zinn-cache/ and serves it from advanced-cache.php before WordPress loads (it adds define( 'WP_CACHE', true ); to wp-config.php for 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 as utm_source are 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_URL is 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 (including WP_REDIS_PASSWORD given as array( 'user', 'password' ), WP_REDIS_PATH and WP_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 run SCAN can define ZINN_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, Apache mod_cache or 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 (the ngx_cache_purge module), 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 by PURGE or BAN; Apache’s disk cache by deleting the entry files. Signed-in visitors, excluded addresses and form posts are sent Cache-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.

Remote purging

A REST endpoint, 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.

Pro costs $49 a year for one site, $99 for five sites and $199 for unlimited sites, and every plan starts with a 14-day free trial, no card needed. Start it from the Pro tab of the Zinn® Cache screen.

External services

Cloudflare (only if you switch on Cloudflare purge)

When Cloudflare purge is on and a zone ID and API token are saved (or ZINN_CACHE_CLOUDFLARE_ZONE and ZINN_CACHE_CLOUDFLARE_TOKEN are defined), the plugin sends the addresses of changed pages on this site to https://api.cloudflare.com/client/v4/zones/<zone>/purge_cache so Cloudflare stops serving the old copies. Nothing else about the site or its visitors is sent. Cloudflare: terms https://www.cloudflare.com/terms/, privacy policy https://www.cloudflare.com/privacypolicy/

Your own site (cache detection)

The Status tab’s Check now button, and a daily check, request a few of this site’s own pages as a visitor would, to read which caches answered. These requests go only to this site’s own address.

AI apps you connect (MCP sign-in)

Only when an AI app such as Claude or ChatGPT starts connecting to the site’s MCP server does the site fetch that app’s public OAuth client metadata from the address the app gives, for example https://claude.ai/oauth/mcp-oauth-client-metadata or https://chatgpt.com/oauth/client.json. No site content is sent.

• Claude: terms https://www.anthropic.com/legal/consumer-terms, privacy policy https://www.anthropic.com/legal/privacy
• ChatGPT: terms https://openai.com/policies/terms-of-use/, privacy policy https://openai.com/policies/privacy-policy/

This plugin can connect your site to Zinn Digital® (the hosting platform it is built for) so that
cache purges can be mirrored to it and the Zinn® dashboard can show what changed on the site.

What is sent, and when

• Cache purges (only if ZINN_CACHE_PANEL_URL and ZINN_CACHE_PANEL_SECRET are defined).
  When content changes, the plugin posts the affected URLs and cache tags — no post content, no
  visitor data — to the address in ZINN_CACHE_PANEL_URL. The request is signed with an HMAC-SHA256
  of the body using your site’s own secret. Note: the Zinn Digital® platform does not define
  ZINN_CACHE_PANEL_URL on the sites it hosts today, so on those sites nothing is sent.

• Outbound link index (only if ZINN_SITE_LINKS_URL and ZINN_CACHE_PANEL_SECRET are defined).
  When a post is saved or removed, and on a daily pass, the plugin sends that post’s title, its
  permalink, and the links found in its content so link placements can be tracked from your
  Zinn® dashboard. This is post-derived data: titles and the URLs a post links to. The post body
  itself is never sent, and no visitor data is included.

• Hosting-customer Pro discount (only on sites Zinn Digital® hosts). The settings screen shows
  administrators a card offering hosting customers a personal discount code for Zinn® Cache Pro.
  Nothing is sent when the page loads. Only when an administrator presses the card’s button does the
  site send one request to Zinn Digital® at https://api.zinndigital.com/v1/wp/pro-discount/<site id>,
  containing the plugin’s slug, the word issue and the administrator’s WordPress language, signed
  with the site’s own key. The site’s address and key come from constants the platform
  writes into wp-config.php on the sites it hosts; the card reuses only the host and site id of the
  address, which ends in /v1/wp/plugin-update/<site id>, and never sends anything to that address
  itself. On any other site they do not exist and the card is never shown. The answer is the
  customer’s code and a Freemius checkout link, to which the browser is then sent. The card is not
  shown once Zinn® Cache Pro is active.

When nothing is sent. The constants above are set by the Zinn® platform when it provisions
a site — except ZINN_CACHE_PANEL_URL, which it does not set today. On a site that is not hosted with Zinn Digital® none of them exist, and the plugin makes no
outbound requests whatsoever unless you opt in to Freemius — caching, exclusions and the object cache all work locally.

Service terms: https://zinndigital.com/legal/terms
Privacy policy: https://zinndigital.com/legal/privacy

• Support diagnostics (only when you press send). If you ask us for help, the plugin can send
  a support report to https://api.zinndigital.com/v1/connector/diagnostics. You are shown the
  exact payload first, already redacted, and nothing leaves your site until you press send.
  Credentials are excluded by declaration rather than by matching key names, and render as
  [not sent — credential]. The plugin never sends this on its own initiative.

Translations

Every string this plugin adds to your admin is translated into 57 languages — labels, notices,
errors and settings, not a subset. The catalogues are bundled in the plugin, so they work as soon
as you set your site language; there is no separate language pack to install.

Every user-visible string is complete in every one of the 53 languages WordPress can serve
today:

Amharic (am), Arabic (ar), Azerbaijani (az), Bulgarian (bg_BG), Bengali (Bangladesh)
(bn_BD), Czech (cs_CZ), German (de_DE), Greek (el), Spanish (Spain) (es_ES), Persian
(fa_IR), French (France) (fr_FR), Gujarati (gu), Hebrew (he_IL), Hindi (hi_IN), Croatian
(hr), Hungarian (hu_HU), Armenian (hy), Indonesian (id_ID), Italian (it_IT), Japanese
(ja), Georgian (ka_GE), Kazakh (kk), Khmer (km), Kannada (kn), Korean (ko_KR), Lao (lo),
Malayalam (ml_IN), Mongolian (mn), Marathi (mr), Malay (ms_MY), Myanmar (Burmese)
(my_MM), Nepali (ne_NP), Dutch (nl_NL), Panjabi (India) (pa_IN), Polish (pl_PL), Pashto
(ps), Portuguese (Brazil) (pt_BR), Romanian (ro_RO), Russian (ru_RU), Sinhala (si_LK),
Albanian (sq), Serbian (sr_RS), Swahili (sw), Tamil (ta_IN), Telugu (te), Thai (th),
Tagalog (tl), Turkish (tr_TR), Ukrainian (uk), Urdu (ur), Uzbek (uz_UZ), Vietnamese
(vi), Chinese (China) (zh_CN)

A further 4 ship complete in the plugin — Hausa (ha), Somali (so_SO), Tajik (tg), Yoruba (yo) — but
WordPress core does not currently provide a locale for them, so WordPress cannot load them.

The catalogues are bundled rather than left to translate.wordpress.org because that site can only
offer what volunteers have contributed, and a site administrator working in Amharic or Khmer would
otherwise read English indefinitely. They do not compete with community translations: where a
WordPress language pack exists for this plugin, WordPress loads it ahead of the bundled catalogue,
so a community translation always wins.

Right-to-left

Arabic, Persian, Hebrew, Pashto and Urdu are right-to-left. Every screen this plugin adds was
rendered in a real WordPress install in each of those languages and checked, not assumed.

For translators

languages/ holds the `.pot` template plus a `.po`, `.mo` and `.l10n.php` for every language, so

corrections and new languages can be contributed directly.