Plain Cookie Consent
| 开发者 | ontario777 |
|---|---|
| 更新时间 | 2026年7月11日 02:48 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.0 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
详情介绍:
- Google Consent Mode v2 defaults injected at
wp_headpriority 1, before any tag manager or gtag snippet. - Early inline consent replay with a revision gate — consent recorded before a policy revision bump is not replayed; the banner re-prompts instead.
- Server-side audit log (
wp_plain_consent_log) with a privacy-preserving SHA-256 subject hash over a daily-rotating salt, and a 730-day default retention purge (filterable via constant). - Consent revision system with a "Force re-consent for all users now" admin action and strict rollback if the audit insert fails.
- Two-step choice pattern: the first layer offers Accept All and Show Options; the preferences screen (one click away) offers equal-weight Accept All, Reject All, and Save Preferences buttons.
- Server-mirror consent cookie via a cache-safe
GET /mirror-nonceendpoint (Cache-Control: no-store), so full-page caching does not break nonce validation. - Geo targeting: the consent-required region set is the EEA (EU-27 plus Iceland, Liechtenstein, Norway) plus the United Kingdom. Detection uses the Cloudflare
CF-IPCountryheader when present, with a fail-safe default: if the country cannot be determined, the visitor is treated as in-scope. - CSV/JSON streamed export of the consent log, plus a Data on uninstall shortcut and contextual deactivation reminder when log rows exist.
- DSAR lookup admin tool: recompute a visitor's subject hash from IP + User-Agent and list matching consent-log entries (GDPR Art. 15 support).
- Meta Pixel: define
PLAIN_COOKIE_CONSENT_FACEBOOK_PIXEL_IDinwp-config.php. - Microsoft Clarity: define
PLAIN_COOKIE_CONSENT_CLARITY_PROJECT_IDinwp-config.php. - LinkedIn Insight Tag: define
PLAIN_COOKIE_CONSENT_LINKEDIN_PARTNER_IDinwp-config.php. - Public
window.plainCookieConsentJavaScript API (getCategories,hasConsent,onChange,onGrant,onRevoke) for site-specific vendors. - Cookie cleanup on revoke with curated defaults for LinkedIn, TikTok, Hotjar, Clarity, Yandex Metrica, and Snapchat (
plain_cookie_consent_autoclear_cookiesfilter). localStorage/sessionStoragecleanup on a real granted-to-revoked transition (plain_cookie_consent_clear_storage_keysfilter).
- The banner and preferences modal are attested against WCAG 2.1 AA.
- axe-core smoke tests (
wcag2a,wcag2aa,wcag21aatags) run on every push and pull request via GitHub Actions. - Site-level accessibility remains the operator's responsibility.
- TCF v2.2 (programmatic publishers).
- Consent analytics dashboards beyond the read-only Consent Health widget.
- Multi-domain consent sync.
- Banner A/B testing.
- Script auto-blocking beyond Consent Mode and the documented vendor helpers.
安装:
- Upload the
plain-cookie-consentfolder to/wp-content/plugins/. - Activate the plugin via the Plugins menu.
- Visit Settings → Cookie Consent to configure the Privacy Policy URL, policy version, and optional data-controller name.
- For Meta Pixel / Microsoft Clarity / LinkedIn Insight: define the relevant constant in
wp-config.php.
屏幕截图:
常见问题:
Is reCAPTCHA covered?
The plugin does not auto-gate reCAPTCHA, because its legal basis is context-dependent: on contact forms it generally requires consent, while as payment anti-fraud it may be consent-exempt. The Diagnostics "reCAPTCHA / security CAPTCHA" probe flags its presence so you can decide. The bundled docs/INTEGRATION.md documents gating patterns.
Diagnostics says the public front page cache may be stale. What should I do?
After a fresh activation or update, full-page cache can keep serving HTML generated before the plugin was active. Diagnostics compares the normal public front page with a cache-busted front-page request for the bootstrap and consent-default source checks. If the cache-busted render contains the plugin markers but the normal public page does not, purge your WordPress page cache, Redis/Varnish/Nginx full-page cache, and Cloudflare/CDN cache, then rerun diagnostics before editing theme or tag-manager code.
Is Switzerland covered?
No. Switzerland (CH) is deliberately excluded from the consent-required region set. The Swiss revFADP has no prior-consent rule for cookies equivalent to ePrivacy Art. 5(3), so Swiss traffic falls under the rest-of-world (granted-by-default) branch. The in-scope set is the EEA (EU-27 + Iceland, Liechtenstein, Norway) plus the United Kingdom.
Does uninstalling the plugin delete its data?
No — not by default. The consent audit log and all plugin settings are preserved when you uninstall (GDPR Art. 7.1 evidence; a reinstall finds prior records and configuration intact). To permanently delete all data, go to Settings → Cookie Consent → Data on uninstall, switch to delete mode (type DELETE to confirm), and then proceed with the WordPress uninstall. The rotating subject salt is always removed in both modes. Exporting the log first (CSV or JSON) is recommended for portable evidence before any permanent deletion.
Does the plugin collect any data itself?
No. There is no external telemetry. Consent records stay in your own WordPress database, with the subject identifier stored only as a salted SHA-256 hash.
更新日志:
- Changed: a consent banner left unanswered now auto-shows again on the next page view in the same browsing session, instead of only once per session. The banner keeps appearing until the visitor makes a choice; visitors with a recorded choice are unaffected.
- Fixed: removed the passive Plugins-page uninstall-data notice that could appear after a normal update or manual ZIP overwrite.
- Fixed: Data-on-uninstall guidance is now contextual: the plugin row links to the dedicated settings section, and the deactivation modal mentions keep/delete behavior only when the consent log has rows.
- Fixed: Data on uninstall actions now show visible success, no-op, and confirmation-required notices after saving the uninstall mode or deleting preserved data.
- Fixed: dismissing the preserved-data reinstall notice no longer removes the marker needed for the settings-page cleanup path.
- Fixed: the preserved-data reinstall notice no longer points to a DSAR review workflow that cannot subject-match records after reinstall.
- Fixed: stale public-cache bootstrap/default misses now appear consistently as actionable diagnostics attention items across admin surfaces.
- Changed: exposed the free front-end runtime configuration for Pro add-on reuse without changing the public browser object shape.
- Fixed: the legacy DSAR admin URL now redirects to the DSAR tab on the main settings page instead of reaching a WordPress access-denied screen.
- Changed: the Settings submenu now uses one compact Cookie Consent entry, with DSAR as a tab beside Settings, FAQ, and Diagnostics.
- Changed: diagnostics indicators are less noisy; the red menu marker now appears only for fix-required findings, and the Plugins list uses plain action links without a diagnostics badge.
- Changed: removed the legacy self-hosted Update URI header and unused self-hosted update constants so manually installed ZIPs can receive normal WordPress.org update offers for the plain-cookie-consent slug.
- Fixed: diagnostics now compares the normal public front page with a cache-busted render for plugin-bootstrap and consent-default source checks, reducing false "Needs fix" guidance after fresh activation behind stale page/CDN cache.
- New: uninstall now keeps the consent audit log and all plugin settings by default (GDPR Art. 7.1 evidence); a reinstall finds prior records and configuration intact. Opt into permanent deletion via Settings → Data on uninstall (typed DELETE confirmation required).
- New: full admin-UI internationalization — all admin strings are now translatable.
- Changed: minimum PHP lowered back to 7.4 (from 8.0); the code is verified 7.4-safe, widening host compatibility.
Full release history is maintained in
CHANGELOG.mdin the plugin package and repository.