Releases: yuri-parfentcov/zen-server-side-cookie-restorer
Release list
v1.6.0 — renamed to Zen Server-Side Cookie Restorer
The plugin is now Zen Server-Side Cookie Restorer (previously Zen Cookie Keeper). The former name overlapped with an existing commercial product offering the same cookie-restoration functionality, so it was dropped ahead of the WordPress.org listing.
What it does is unchanged: it writes and restores your first-party analytics and advertising cookies with a server Set-Cookie, so Safari ITP and Firefox ETP stop capping them at 7 days — consent-gated, with no server-side GTM container.
Upgrading is automatic. Existing tables, options and stored visitor identities are renamed in place on the first request after the update; nothing is recreated and no identity is lost. The anchor cookie name is deliberately unchanged, so visitors stay recognised across the upgrade.
Also in this release: the daily retention cleanup is now rescheduled by the upgrade rather than only on activation, so it cannot stop silently on a site that updates without reactivating — which also fixes it for multisite sites that never ran the activation hook.
v1.5.2 — bootstrap every site on multisite
Fixes a silent failure on multisite and adds the diagnostic that would have caught it.
Fixed — network-activated multisite set up only one site. The activation hook fires once, for the activating site. Every other site in the network, and every site added later, reached its first request with tables but no seeded options — so no sync token, every sync request rejected, and no cookie ever written or restored. The admin screens rendered normally, which made it invisible. The lazy database upgrade now seeds options as well as creating tables, so any site bootstraps itself completely. Affected installs repair themselves on the next request after updating; settings you have already changed are preserved.
New — sync-token health row in Diagnostics. A site that cannot write cookies now says so instead of failing silently. It reports presence only, never the token itself.
Documentation. readme.txt corrected against the code: the admin menu is "Zen Cookie Keeper", the registry is eight cookies across Google Analytics, Google Ads, Microsoft Ads, Meta, TikTok and LinkedIn with their default lifetimes stated, and multi-domain and multisite scoping is described as it actually works, with a new FAQ entry.
Plugin Check 2.0.0: all 32 checks with low severity included, zero findings on the distributed file set.
Both assets are identical; zen-cookie-keeper-latest.zip feeds the stable download URL.
v1.5.1 — accurate restore history
Fixes cookies being logged as restored when they were never lost, and rebuilds the Restore History screen around what actually happened.
The fix
The companion script only reported capture-source cookies back to the server. For the five the plugin mints — _gcl_aw, _gcl_dc, _fbc, _uetmsclkid, li_fat_id — that meant the server could not tell "the browser lost this" from "nobody asked about it". It read the silence as missing: re-sent the cookie and wrote a restore row, on every sync, indefinitely.
Measured on a live install: three ordinary syncs produced three "missing" rows for a cookie that was sitting in the browser intact. One ad visitor reading five pages generates roughly ten rows per session, so a site doing a thousand such sessions a day would have written around 3.6 million rows a year — essentially all of them false.
The companion now reports every cookie JavaScript can read, and the server fills in HttpOnly ones from the request its own Cookie header carries. A cookie counts as missing only when it is absent from both.
Verified after the change: the same three syncs produce zero rows, a genuinely deleted cookie is still detected, re-emitted and logged as missing, and a changed value still logs divergent.
If you have been running an earlier version, your existing restore history is inflated by this — the totals, the chart and the average identity age all count events that never happened. The rows age out on their own retention schedule, or you can clear the table and start from clean numbers.
Restore History, rebuilt
The screen no longer renders one flat row per cookie, capped at 200 with no way to reach row 201. It now reads one line per visitor per moment — a single sync can bring several cookies back at once:
2026-07-27 06:23 · visitor
#31· 2 missing · 1 divergent
_fbpmissing, identity 13 days old ·_gamissing, 42 days ·_gcl_awdivergent, 3 days
25 events per page, with paging. The CSV export is unchanged and still contains the individual rows.
wp plugin check: 0 errors, 0 warnings.
v1.4.0 — WordPress.org compliance hardening
Prepares the plugin for WordPress.org submission and rebuilds the admin screens. No change to how cookies are minted, captured or restored.
Compliance hardening
Audited against the WordPress.org plugin guidelines. Most of the checklist already passed; five things did not:
extract()removed from the admin view loader — each template now names its variables explicitly.- The Restore History chart data moved from a hand-written
<script type="application/json">block towp_add_inline_script(), so nothing bypasses the enqueue API. - The last raw
echoof assembled markup is gone from Diagnostics; there are now zeroEscapeOutputignores in the plugin. - Every echo has a bare escaper as its outermost call.
- The two
@preg_matchcalls that must stay carry targeted, justified annotations.
Admin screens rebuilt
All six screens share one panel and field system. Labels sit above their inputs, so inputs line up on a single left edge instead of starting wherever the label text ended. The cookie catalog is one table with platform separators rather than six tables each repeating an identical header. Sites & domains lists active cookie-domain overrides with a Remove action and says whether the resolved domain came from an override or was derived.
Diagnostics is now pass/check health rows that say whether a finding needs action, and surfaces the stored-row counts and resolved client IP it previously collected but never displayed.
Fixed: the cookie-writer collision check matched plugins by main-file path and silently missed GTM4WP, whose file name does not match its folder. It now matches on directory slug and covers network-activated plugins.
Upgrade note
A table and option left over from an earlier version are removed automatically on the first request after upgrading.
wp plugin check: 0 errors, 0 warnings.