Wiwi Cookie Consent
| 开发者 | naiches |
|---|---|
| 更新时间 | 2026年10月6日 02:12 |
| PHP版本: | 8.0 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPL-2.0-or-later |
| 版权网址: | 版权信息 |
详情介绍:
Wiwi Cookie Consent is a small, dev-friendly consent banner. Add your tracking scripts (Google Analytics 4, Meta Pixel, Google Ads, or anything else) through the settings page, and the plugin blocks them from running until a visitor actually consents to that category — nothing more, nothing less.
Built for typical brochure/marketing sites without visitor accounts or logins — not for membership sites, and not a full cookie-compliance suite. See "What it deliberately does not do" below for the exact boundary.
What it does
- Opt-in by default — every category starts OFF; nothing tracks until a visitor chooses to allow it.
- Real script blocking — tracking code is wrapped in an inert
<template>element and only activated after consent, not just hidden with CSS. - Per-category consent — Marketing, Analytics, and Functional, each independently toggleable in the preferences modal, plus an always-on Necessary section that lists the essential cookies.
- Quick-add templates for Google Analytics 4, Meta Pixel, and Google Ads — enter your ID, done.
- Fully accessible — keyboard navigation, focus trap, ARIA attributes on the preferences modal.
- Style it yourself — an optional toggle disables the plugin's own CSS entirely while keeping every ID and class in place, so you can theme the banner from your own stylesheet.
- Dutch and English out of the box.
- No consent logging. Nothing about your visitors is stored server-side — no IP, no timestamp, no consent database. Built for anonymous-visitor sites without accounts/logins; there's no identified user to tie a server-side consent record to in the first place. See the notice on the plugin's own settings page for the full reasoning.
- No validation of how you classify a cookie. You decide which category (Marketing/Analytics/Functional) each cookie belongs to, and the plugin blocks/unblocks it accordingly — correctly and reliably. It cannot know whether you classified it correctly (e.g. labelling an analytics cookie as "Functional" to skip consent is a real, commonly-fined mistake). Getting the categories right is your legal responsibility.
- No site-wide cookie scanning or auditing. The plugin doesn't crawl your site to discover what cookies exist — you declare them yourself in the cookie table. Automatic cookie discovery is a fundamentally different (and much heavier) category of tool; see the FAQ.
- No scanning or filtering of other plugins, themes, or embedded content. This plugin only gates the tracking code you configure through its own settings — it will not detect or block a hardcoded script elsewhere on your site, or a YouTube/Maps/social-widget embed. Continuously scanning and filtering arbitrary page content would need to watch the DOM on every page (e.g. a
MutationObserver), which runs against this plugin's zero-front-end-impact design goal. That stays your responsibility — self-host fonts, use privacy-enhanced embed modes, or click-to-load placeholders. - No Terms, Privacy Policy, or Cookie Policy content. The Banner & Modal Text settings let you link to existing WordPress pages for these — the plugin does not write, generate, or validate their content. You (or your agency) must write and maintain Algemene voorwaarden, Privacybeleid/Privacyverklaring, and Cookiebeleid yourselves.
- No bundled updater, no telemetry, no phone-home. Updates come from the WordPress.org repository like any other plugin.
安装:
- Upload the
wiwi-cookie-consentfolder to/wp-content/plugins/, or install the zip via Plugins → Add New → Upload Plugin. - Activate the plugin through the Plugins menu in WordPress.
- Open the new Cookies menu in the admin sidebar.
- Add your tracking code per category (or use the quick-add templates), customise the banner text, and save.
屏幕截图:
常见问题:
Does this plugin store or log what visitors consented to?
No. There is no server-side consent database. See "What it deliberately does not do" above and the notice shown at the top of the plugin's own settings page.
Does it block cookies from other plugins or themes?
No. It only gates tracking code entered through its own settings screen. If you have a tracking script hardcoded in your theme or added by another plugin, route it through Wiwi Cookie Consent's settings if you want it consent-gated, or handle it separately.
Does it check whether I've categorised my cookies correctly?
No. The plugin blocks and unblocks exactly what you tell it to, exactly as configured — that mechanism is reliable. Whether a given cookie genuinely belongs in Marketing, Analytics, or Functional (and whether "Functional" is even the correct exemption for it) is a legal judgement call only you can make. Mislabelling a tracking cookie as "Functional" to avoid asking for consent is one of the most common cookie-banner violations regulators actually fine — the plugin can't catch that for you.
Can this plugin scan my site and find all my cookies for me?
No, and that's intentional. Automatic cookie/tracker discovery is a genuinely different, much heavier category of tool (the kind built by dedicated consent-management platforms). This plugin stays a lightweight blocker for the tracking code you explicitly configure — it does not crawl pages, inspect third-party scripts, or maintain its own cookie database.
Do I still need to write my own Privacy Policy / Terms / Cookie Policy?
Yes, always. The plugin lets you link the banner to existing WordPress pages for Terms & Conditions, Privacy Policy, and Cookie Policy — it does not write or supply any legal content. That text is your (or your agency's) responsibility.
Does it collect any data or phone home?
No. There is no usage tracking, analytics, telemetry, or licensing call-home.
Can I fully restyle the banner?
Yes. Enable "Don't load the plugin's default stylesheet" under Styling in the settings page, and style #wcc-cookie-banner, #cookie-preferences-modal, .wcc-btn, .wcc-toggle, and the other existing classes/IDs from your own theme CSS. The banner's show/hide and open/close behaviour works independently of the stylesheet.
更新日志:
1.0.3
- Added: a Settings link in the plugin's row on the Plugins screen.
- Fixed: on a site with page caching, changing the cookie list or tracking code made visitors be asked again on page after page, and tracking ran only on some pages: cached pages still carried the old setup while new pages carried the new one. Saving a change that re-asks visitors now clears the page cache of WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super Cache, WP Fastest Cache, SiteGround, Cache Enabler, Breeze, Hummingbird, Nginx Helper and WP Engine, and the settings screen tells you to clear any other cache or CDN. A new
wicc_config_version_changedaction lets a host-specific purge hook in. - Fixed: a fresh install on a non-English site showed the banner in English. Activation stored the default texts before the plugin's translation had loaded, and stored text wins over the translated default. Nothing is stored on activation any more; empty fields show the default in the site's language, as the settings screen already said. On sites where this already happened, banner texts still exactly equal to the English default are cleared once, so the translation shows; anything you edited is left alone.
- Fixed: on multilingual sites with a language folder in the address (WPML's /en/), consent given on a page in one language did not count on pages in the other. Consent cookies now always use the site's own path. Consent stored under the language folder by earlier versions is cleared, so those visitors are asked once more.
- Fixed: a returning visitor's consent reached Google Consent Mode only after Google tags loaded outside this plugin (Site Kit, GTM, a header snippet) had already sent the page view, so each of their page views was counted as not consented. The stored choice is now restored in the page head, straight after the deny-by-default.
- Fixed: a snippet that loads a library and then calls it (a script with
srcfollowed by an inline script) ran the call first, so the snippet failed. Scripts at the top level of a snippet now run in the order they are written, as they would in the page itself; scripts the snippet marksasyncstill load without waiting, and if the visitor withdraws consent while a script is still loading, the rest of the snippet is not run. - Fixed: a non-JavaScript script block in a snippet, such as JSON-LD structured data, was run as JavaScript and threw an error. Script types are now kept as written; only
text/plainis still run as JavaScript. - Fixed: after visitors were asked again because the configuration changed, pressing Reject All announced "Changes take full effect on your next page load" to screen readers although nothing had run.
- Fixed: on multisite, a site administrator who is not allowed to add unfiltered HTML could edit a category's code, see "Settings saved." and lose the edit without notice. The code field is now read-only for them, with an explanation, and a submitted change is reported as not saved.
- Fixed: "Add a known service" replaced the field name anywhere inside a declared cookie name supplied through the
wicc_tracking_templatesfilter (the "ID" inIDE, for example). It now replaces only a whole_-separated part or a{{ID}}-style placeholder.
- Security: editing a category's tracking code so that a commented-out tracker became live again did not count as a change, so returning visitors were never asked again and the tracker started under consent they gave before it existed. The check that decides "has what I am consenting to changed?" treated a line break as ordinary spacing — and a line break is exactly what ends a JavaScript comment. Line breaks are now significant; reindenting or reformatting still does not re-prompt anyone.
- Fixed: when visitors were asked again because the configuration had changed, the Functional switch could come up already ticked, filled in from a cookie left by an older version of this plugin. Pressing Save without touching anything then granted exactly the tracking they were being asked about. Being asked again now always starts from everything off, as a first visit does, while visitors whose consent still stands keep their existing choices.
- Security: a link in the banner description with a crafted
relvalue could inject markup into the page for every visitor (the reverse-tabnabbing rewrite used the admin's ownreltokens as a regex replacement pattern).reltokens are now allow-listed and the rewrite is literal. On a stock single site the admin already hasunfiltered_html, so the practical impact is on multisite andDISALLOW_UNFILTERED_HTMLsites, where it bypassed the restriction core deliberately places on site administrators. - Fixed: backslashes in a category's code were stripped on every save (a regex
/\d+/became/d+/, thend+), because the code was unslashed twice. A pasted snippet now survives any number of saves unchanged. - Added: visitors are asked again when what they are being asked to consent to changes — a category gains tracking code, a tracker is added to a category, or the declared cookies change. The banner returns and nothing activates until they confirm; existing consent is otherwise untouched. Nothing per-visitor is stored: a single fingerprint of the site's configuration travels with the consent cookies. Rewording a description does not re-ask. Consent recorded before this release carries no fingerprint at all, so there is no way to tell which configuration it was given under — including whether a tracker has been added since. Those visitors are therefore asked once more after this update, and nothing activates for them until they answer; every choice from then on is anchored and only a real change asks again.
- Added: an always-on "Necessary" section leads the Manage cookies window, so the essential cookies the banner text mentions are actually listed and explained rather than only asserted. It has its own "What visitors are told" field and declared cookies on the settings screen, no switch and no code field.
- Changed: the default Dutch copy is informal (je/jouw) throughout, and the service descriptions and cookie durations offered by "Add a known service" are English in the source and translated, instead of Dutch text on every site regardless of language. Sites activated before this change keep whatever text they already have.
- Changed: the default banner text now points to "the cookie icon in the corner of the page" — the reopen control is an icon, so the old "'Cookie settings' link" named something sighted visitors could not find.
- Fixed: per-service descriptions in the Manage cookies window fell just short of WCAG AA contrast on the category card background.
- Fixed: the policy-page pickers offered every draft and trashed page as a plain title; only published pages are offered now, and a selected page that is no longer published stays selectable but is labelled as not visible to visitors.
- Changed: script/style handles and JavaScript globals are prefixed. Every front-end element ID and class is unchanged, so custom CSS targeting the banner, the preferences window, the buttons or the switches keeps working exactly as before.
- Changed: the front-end script and stylesheet are no longer loaded on a site with nothing configured to consent to, and the skip link's critical CSS is attached through the enqueue API instead of a raw style tag.
- Added: a
wicc_tracking_templatesfilter so a theme or site plugin can add its own service to the "Add a known service" picker. - Fixed: on the settings screen, a declared cookie name or field label containing
$&,$'or a backreference was mangled in the "Add a known service" description instead of shown as typed. - Fixed: the Dutch translation that ships with the plugin was never loaded. WordPress only picks up translations from its own languages folder automatically, so until translate.wordpress.org carries this plugin, Dutch sites saw English. The bundled translation is now registered and loads; a translation from translate.wordpress.org still takes precedence when one exists.
- Fixed: the three Save buttons on the settings screen shared one element ID, which confused assistive technology and made the page fail an accessibility check. Each now has its own.
- Fixed: Google Consent Mode could be told a visitor had consented after they pressed Reject All. The signal was sent based on the individual category cookie alone, without checking whether consent had been given at all — unlike the tracking code itself, which did check and correctly stayed blocked. A category cookie outlives the category it belongs to (Reject All only rewrites the categories currently on screen), so a visitor who accepted once, and later rejected after that category was removed, kept sending "granted" on every page load.
- Fixed: text pasted into a category's tracking code field was inserted into the page as visible content the moment a visitor accepted that category. Anything without a script or stylesheet tag is now ignored at insertion time, so it can never reach a visitor.
- Added: each category now has a "What visitors are told" field, shown under that category in the Manage cookies window. Category explanations previously had nowhere to go, which is what led people to put them in the code field.
- Changed: the settings screen is rebuilt around one card per category, holding that category's explanation, its code, and the cookies it declares. Banner and modal copy, styling and consent settings move to their own tabs.
- Added: saving a code field that contains no script or stylesheet tag now warns, and the category is flagged on screen until it is resolved.
- Added: "Add a known service" now asks for whatever that service actually needs — Adobe Fonts for a kit ID, Google Analytics for a measurement ID — with a note on where to find it and which cookies it will declare. Adobe Fonts and Google Fonts are now included.
- Fixed: a stylesheet or meta tag activated on consent no longer announces "additional content has been added to the page" to screen readers, since nothing visible was added.
- Initial release.