Zinn® Cache

Zinn® Cache connects a WordPress site to the server-side cache layer of the Zinn Digital® hosting platform. It is installed for you when a Zinn® site is provisioned. It runs on LiteSpeed Enterprise / OpenLiteSpeed hosts with the LSCache module, and degrades gracefully wherever a cache layer is absent — caching is a per-blueprint capability.

Which Zinn® cache plugin do I need? Exactly one of them:

• Hosted with Zinn Digital® — this plugin. Your Zinn® server already runs the page cache; Zinn® Cache controls it and connects it to your dashboard.
• Hosted anywhere else — install Zinn® Cache Engine, which brings its own caching engine.

They are different plugins doing different jobs, not a free and a paid tier of one plugin. You do not need both.

What it does

• LSCache control. Stamps X-LiteSpeed-Cache-Control and X-LiteSpeed-Tag headers on cacheable front-end responses so the LiteSpeed web server can serve full pages without hitting PHP or MySQL. A configurable public cache lifetime is applied. 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, the theme is switched, a plugin is (de)activated, or WordPress/plugins/themes are updated — only the affected pages (and the listings they appear on) are purged, via targeted LiteSpeed cache tags. 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. The plugin never overwrites another caching plugin’s drop-in, and the drop-in falls back to an in-memory cache if Redis is unreachable, so the site keeps working.
• 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.

One-click admin login

On Zinn-hosted sites, GET /wp-json/zinn-sso/v1/login accepts a short-lived signed token issued by the Zinn® dashboard and opens a wp-admin session for the site’s administrator — no password, and no second set of credentials to manage. Tokens are signed with the site’s own key (ZINN_SSO_KEY), are bound to this site (ZINN_SITE_ID), expire after about two minutes, and can only be used once. The route is not registered at all unless both constants are defined, so the endpoint does not exist on a site that has not been given a key.

External services

This plugin can connect your site to Zinn Digital® (the hosting platform it is built for) so that
an administrator can open wp-admin from the Zinn® dashboard without a second password, and so the
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.

• One-click admin login (only if ZINN_SSO_KEY and ZINN_SITE_ID are defined). This is
  inbound only — Zinn Digital® presents a short-lived signed token and the plugin verifies it. No
  request leaves your site, and the route is not registered at all unless both constants are set.

• 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.

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 — 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.

All 56 user-visible strings are 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.