Compatibility with page caching \u2014 the settings version is part of the script URL<\/li>\n<\/ul>\n\nWhat ships pre-configured<\/h4>\n\n
Strictly Necessary<\/strong>, always on: cc_cookie<\/code>, wordpress_logged_in_*<\/code>, wordpress_sec_*<\/code>, wordpress_test_cookie<\/code>, wp-settings-*<\/code>, wp_woocommerce_session_*<\/code>, woocommerce_cart_hash<\/code>, woocommerce_items_in_cart<\/code>, woocommerce_recently_viewed<\/code>, PHPSESSID<\/code>.<\/p>\n\nPerformance and Analytics<\/strong>, off until accepted: Google Analytics (_ga*<\/code>, _gid<\/code>, _gat<\/code>), Matomo (_pk_*<\/code>, mtm_*<\/code>) and SourceBuster (sbjs_*<\/code>).<\/p>\n\nWhat it does not do<\/h4>\n\n
Stated plainly, so you can rule it out in thirty seconds rather than after installing:<\/p>\n\n
\n- No consent log.<\/strong> The visitor's choice is stored in their own browser, in
cc_cookie<\/code>. Nothing is written to your database, so there is no proof-of-consent export.<\/li>\n- No Google Consent Mode v2 signals.<\/strong><\/li>\n
- No automatic cookie scanner.<\/strong> You list the cookies you want managed.<\/li>\n
- No CCPA \"Do Not Sell\" flow.<\/strong><\/li>\n
- No automatic translation.<\/strong> Six languages ship for the interface strings. The text you write yourself \u2014 title, description, button labels, category names \u2014 is stored once, in whatever language you type it.<\/li>\n<\/ul>\n\n
A note on compliance<\/h4>\n\n
This plugin gives you the mechanism: blocking before consent, granular categories, a choice the visitor controls, and a way to revisit it. Whether your site is compliant depends on how you configure it and what your site actually loads. It is a tool, not legal advice.<\/p>\n\n
For developers<\/h4>\n\n
Hold any script until a category is accepted:<\/p>\n\n
<script type=\"text\/plain\" data-category=\"analytics\" src=\"...\"><\/script>\n<\/code><\/pre>\n\nOr block a script that another plugin registered, by handle:<\/p>\n\n
add_filter( 'warder_blocked_scripts', function ( $scripts ) {\n $scripts['my-analytics-handle'] = 'analytics';\n return $scripts;\n} );\n<\/code><\/pre>\n\nSource Code<\/h3>\n\n
This plugin ships no obfuscated or minified-only code. The only compiled asset is dist\/cookieconsent.bundle.js<\/code>, bundled from human-readable source with webpack. Its first lines are a comment banner pointing back to the source. The uncompressed source (src\/index.js<\/code> and webpack.config.js<\/code>) is included in the plugin download, and the full development repository is public:<\/p>\n\nhttps:\/\/github.com\/imagewize\/warder-cookie-consent<\/p>\n\n
src\/index.js imports the [vanilla-cookieconsent v3](https:\/\/github.com\/orestbida\/cookieconsent) library. To build from source: run `npm install`, then `npx webpack` (or `npx webpack --watch` during development).\n<\/code><\/pre>\n\n\n\n- In WordPress go to Plugins > Add New<\/strong>, search for \"Warder Cookie Consent\", then Install and Activate. Or upload the plugin folder to
\/wp-content\/plugins\/<\/code> and activate it there.<\/li>\n- Open Settings > Warder Consent<\/strong>.<\/li>\n
- Set your Privacy Policy URL<\/strong>. It ships as a placeholder, so this is the one setting you should not skip.<\/li>\n
- Review the Performance and Analytics<\/strong> category and add any cookies your site sets that are not already listed.<\/li>\n
- Mark any third-party scripts you embed yourself with
data-category=\"analytics\"<\/code>.<\/li>\n<\/ol>\n\nThe banner appears straight away for visitors who have not yet made a choice. Nothing else is required.<\/p>\n\n\n
\nDoes this make my site GDPR compliant?<\/h3><\/dt>\nNo plugin can promise that. This one gives you the parts a consent flow needs \u2014 scripts held until consent, categories the visitor chooses individually, and a way to change that choice later. Compliance still depends on configuring it for what your site actually loads, and on the rest of your privacy practices.<\/p><\/dd>\n
Does it block Google Analytics before consent?<\/h3><\/dt>\nIt clears Google Analytics cookies, and it will hold the GA script if that script carries data-category=\"analytics\"<\/code> or if you register its handle through the warder_blocked_scripts<\/code> filter. If you load GA through another plugin, add that plugin's script handle to the filter \u2014 see the developer section above. Only WooCommerce order attribution and SourceBuster are blocked automatically.<\/p><\/dd>\nDoes it work with Google Tag Manager?<\/h3><\/dt>\nYou can hold the GTM container itself the same way, with data-category<\/code> on the snippet. The plugin does not emit Google Consent Mode v2 signals, so if your setup depends on those, this is not the right plugin for you.<\/p><\/dd>\nDoes the plugin send any data anywhere?<\/h3><\/dt>\nNo. It makes no external HTTP requests at all. The consent script is served from your own domain, and the visitor's choice is stored in their browser in the cc_cookie<\/code> cookie. Nothing is transmitted to us or to anyone else.<\/p><\/dd>\nDoes it keep a record of who consented?<\/h3><\/dt>\nNot on the server. The record lives in the visitor's own browser. If you need an auditable, exportable consent log stored in your database, use a plugin built for that.<\/p><\/dd>\n
Will it slow my site down?<\/h3><\/dt>\nThe frontend is a single script, loaded deferred, about 18KB gzipped, plus a small inline stylesheet for the floating button. There are no external requests and no jQuery dependency.<\/p><\/dd>\n
Can I use it in a language other than English?<\/h3><\/dt>\nYes. Pick English, Dutch, German, French, Spanish or Italian under Settings > Warder Consent<\/strong> and the interface strings \u2014 \"Manage preferences\", \"Accept current selection\", the close label and so on \u2014 follow. The text you write yourself, such as the banner title, description, button labels and category names, is stored as you type it, so you write that part in your own language.<\/p><\/dd>\nIs it compatible with caching plugins?<\/h3><\/dt>\nYes. Settings are versioned with a timestamp that becomes part of the script URL, so a cached page always pulls the matching configuration.<\/p><\/dd>\n
How do I add custom cookie categories?<\/h3><\/dt>\nSettings > Warder Consent<\/strong>, then \"Add New Category\" at the bottom of the page. Each category gets its own title, description and cookie list, and appears as a toggle in the preferences modal.<\/p><\/dd>\nWhich cookies are managed by default?<\/h3><\/dt>\nWordPress and WooCommerce session cookies are marked strictly necessary, and Google Analytics, Matomo and SourceBuster cookies sit in an analytics category that is off until accepted. The full list is in the description above, and all of it is editable.<\/p><\/dd>\n
Can visitors change their mind after accepting?<\/h3><\/dt>\nYes. The floating cookie button reopens the preferences modal at any time, and you can put it in any of the four corners or turn it off.<\/p><\/dd>\n\n<\/dl>\n\n\n
2.2.0<\/h4>\n\n
2026-08-25<\/em><\/p>\n\n\n- Fixed: choosing any language other than English stopped the consent banner from appearing at all.
src\/index.js<\/code> set the banner language from the settings but only ever defined English strings, and the library throws from run()<\/code> when the selected language has no translation. Because run()<\/code> is async, that rejection escaped the surrounding try\/catch and surfaced as an unhandled promise rejection with no banner on the page. Reproduced in a browser before and after the fix.<\/li>\n- Added: real interface translations for Dutch, German, French, Spanish and Italian, so all six options in the language dropdown now work. The strings you write yourself \u2014 title, description, button labels, category names \u2014 continue to override the built-in text for whichever language is selected.<\/li>\n
- Added: an English fallback. An unknown or stale language code now renders the banner in English instead of stopping it, so a bad stored value can never leave a site with no consent banner.<\/li>\n
- Fixed: removed twelve
console.log<\/code> calls that shipped in the production bundle and ran for every visitor, including a dump of the plugin settings and the final consent configuration. Genuine error reporting is kept and now carries a \"Warder Cookie Consent:\" prefix.<\/li>\n- Fixed:
CookieConsent.run()<\/code> is awaited properly, so an initialisation failure is reported to the console instead of becoming a silent unhandled rejection.<\/li>\n- Listing: rewrote the plugin description around what the plugin does and who it suits, rather than which library it wraps. Adds the pre-configured WordPress\/WooCommerce and analytics cookie defaults, a developer section covering
data-category<\/code> and the warder_blocked_scripts<\/code> filter, and an explicit \"What it does not do\" list \u2014 no consent log, no Consent Mode v2, no cookie scanner, no CCPA flow \u2014 so the plugin can be ruled in or out before installing.<\/li>\n- Listing: plugin title is now \"Warder Cookie Consent - GDPR Cookie Banner\", the short description leads with what it does instead of naming the bundled library, and the tags moved from single words to the phrases people search (
cookie banner<\/code>, cookie consent<\/code>, consent management<\/code>).<\/li>\n- Listing: expanded the FAQ from four questions to eleven, covering the ones that actually decide the install \u2014 whether it blocks Google Analytics and GTM, whether it sends data anywhere, whether it keeps a consent record, page weight, and language.<\/li>\n
- Docs:
== Source Code ==<\/code> moved below the changelog. The directory concatenates unrecognised sections into the Details tab in file order, so keeping it directly under the feature list put build instructions ahead of the description for every visitor.<\/li>\n<\/ul>\n\n2.1.6<\/h4>\n\n
2026-08-13<\/em><\/p>\n\n\n- Confirmed compatibility with WordPress 7.1 and updated
Tested up to<\/code>.<\/li>\n- Build: updated webpack, css-loader, and PHP_CodeSniffer\/WPCS tooling to their latest in-range versions; no functional changes.<\/li>\n<\/ul>\n\n
2.1.5<\/h4>\n\n
2026-06-26<\/em><\/p>\n\n\n- Fixed: added
padding: 0<\/code> to .warder-preferences-toggle<\/code> to prevent Astra Pro theme button styles (padding: 15px 30px) from distorting the floating toggle button and hiding its icon.<\/li>\n- Props: gbogdan for reporting and fixing the Astra Pro CSS incompatibility.<\/li>\n<\/ul>\n\n
2.1.4<\/h4>\n\n
2026-06-04<\/em><\/p>\n\n\n- Listing: added screenshots and captions for the admin settings page, frontend consent modal, cookie category management, the opt-in analytics defaults, and regex cookie matching. No functional changes.<\/li>\n<\/ul>\n\n
2.1.3<\/h4>\n\n
2026-06-03<\/em><\/p>\n\n\n- Build: the compiled
dist\/cookieconsent.bundle.js<\/code> now begins with a comment banner (via webpack BannerPlugin<\/code>) pointing to the uncompressed source and the public repository, so the source location is visible from within the compiled file itself. Comment extraction to a separate .LICENSE.txt<\/code> is disabled so the banner stays inline.<\/li>\n- Docs: moved the
== Source Code ==<\/code> section higher in readme.txt (directly after the feature list) so the human-readable source reference is easy to find. No functional changes.<\/li>\n<\/ul>\n\n2.1.2<\/h4>\n\n
2026-05-30<\/em><\/p>\n\n\n- Docs: added
CONTRIBUTING.md<\/code> at the repository root with build-from-source, development setup, dependencies, and contribution guidelines.<\/li>\n- Docs: moved the developer-facing build\/development\/dependencies sections out of the README into
CONTRIBUTING.md<\/code>, leaving a short \"Contributing\" pointer; renumbered the Composer install method.<\/li>\n<\/ul>\n\n2.1.1<\/h4>\n\n
2026-05-30<\/em><\/p>\n\n\n- Changed: removed
wp_slimstat<\/code> from the default warder_blocked_scripts<\/code> list \u2014 Slimstat is not bundled with WordPress or WooCommerce, so blocking it by default was dead code for most sites. Add it back via the warder_blocked_scripts<\/code> filter if needed.<\/li>\n- Docs: updated README to document the necessary-category cookie defaults (WordPress core + WooCommerce) and analytics defaults (including
sbjs_*<\/code>); added common warder_blocked_scripts<\/code> examples for Slimstat and MonsterInsights.<\/li>\n<\/ul>\n\n2.1.0<\/h4>\n\n
2026-05-30<\/em><\/p>\n\n\n- Added:
warder_block_script_until_consent()<\/code> \u2014 rewrites known analytics\/marketing script tags to type=\"text\/plain\" data-category=\"<category>\"<\/code> so they are held by vanilla-cookieconsent until the user accepts the matching category. Covers sourcebuster-js<\/code> (SourceBuster.js), wc-order-attribution<\/code> (WooCommerce order attribution), and wp_slimstat<\/code> (Slimstat Analytics) out of the box. Extend or replace the list with the warder_blocked_scripts<\/code> filter.<\/li>\n- Added: expanded
necessary<\/code> category cookie defaults to cover the full WordPress and WooCommerce session surface: cc_cookie<\/code>, wordpress_logged_in_*<\/code>, wordpress_sec_*<\/code>, wordpress_test_cookie<\/code>, wp-settings-*<\/code>, wp_woocommerce_session_*<\/code>, woocommerce_cart_hash<\/code>, woocommerce_items_in_cart<\/code>, woocommerce_recently_viewed<\/code>, PHPSESSID<\/code>. Existing installs are unaffected (defaults only apply to new installs or when the necessary category has no cookies configured).<\/li>\n- Changed:
sbjs_*<\/code> (SourceBuster.js attribution cookies) moved from the necessary<\/code> category to analytics<\/code> in the default configuration \u2014 they are set by an optional tracking script, not by WordPress core.<\/li>\n<\/ul>\n\n2.0.2<\/h4>\n\n
2026-05-30<\/em><\/p>\n\n\n- Security: settings save handler now sanitizes the full
$_POST['warder_options']<\/code> array through a dedicated recursive sanitizer (warder_sanitize_options_input<\/code>) before validation, instead of relying on a phpcs:ignore<\/code> suppression. Description fields keep safe post HTML (wp_kses_post<\/code>); all other fields are treated as plain text.<\/li>\n- Security: category and cookie delete handlers now verify the nonce before any request data is used to change state, and call
wp_die()<\/code> on a failed check.<\/li>\n- Hardening:
warder_validate_options()<\/code> now guards every field with isset()<\/code> (no PHP warnings on partial submissions under WP_DEBUG<\/code>) and constrains current_lang<\/code> to the supported language whitelist.<\/li>\n- Fixed: removed the inappropriate
wp_strip_all_tags()<\/code> wrapper around the static preferences-toggle CSS (it is an HTML helper, not a CSS escaper).<\/li>\n- Refactored: the supported languages and preferences-toggle positions now come from two shared helpers (
warder_allowed_languages()<\/code>, warder_allowed_toggle_positions()<\/code>) used by both validation and the admin dropdowns, instead of being hand-copied across three files. No change to available options or behaviour.<\/li>\n- Refactored: removed an unused internal function (
warder_render_category_title_field()<\/code>) that was dead code.<\/li>\n- Docs: clarified the \"Source Code\" section to state that uncompressed source ships in the plugin (
src\/index.js<\/code>, webpack.config.js<\/code>) and in the public GitHub repository.<\/li>\n- Tooling:
phpcs.xml<\/code> now lints the inc\/<\/code> directory (previously only the main file was scanned).<\/li>\n<\/ul>\n\n2.0.1<\/h4>\n\n
2026-05-28<\/em><\/p>\n\n\n- Fixed: necessary category enabled\/readonly values were silently overwritten as false on every admin settings save because the disabled checkboxes were not submitted by form.serialize(). The necessary category is now always forced to enabled=true and readonly=true in validation, regardless of form input.<\/li>\n
- Fixed: is_regex was always saved as true for every cookie. The hidden input used value=\"\" for false, so PHP's isset() returned true for the empty string, silently marking non-regex cookies (_gid, _gat) as regex patterns and corrupting the autoClear cookie list. The hidden input now outputs '0' for false; validation uses !empty() with an explicit '0' check so only the string '1' is treated as true.<\/li>\n
- Fixed: non-necessary categories (e.g. Analytics) appeared as locked and pre-selected in the frontend preferences modal. Validation now always saves enabled=false, readonly=false for non-necessary categories; src\/index.js derives enabled\/readOnly from the category id rather than DB values; admin UI replaces confusing enabled\/readonly checkboxes with descriptive lock\/unlock icons.<\/li>\n
- Fixed: AJAX save no longer returns a misleading \"No changes detected\" message when a setting is toggled back to its current DB value \u2014 the response is always \"Settings saved successfully.\"<\/li>\n<\/ul>\n\n
2.0.0<\/h4>\n\n
2026-05-28<\/em><\/p>\n\n\n- Changed: plugin logic split from one monolithic file into five focused files under
inc\/<\/code> \u2014 defaults.php<\/code>, settings.php<\/code>, ajax.php<\/code>, admin.php<\/code>, frontend.php<\/code>. Main plugin file is now 26 lines (header, constants, requires). No behaviour changes.<\/li>\n- Fixed: admin page title renamed to \"Warder Cookie Consent\"; Settings sidebar label renamed to \"Warder Consent\"<\/li>\n<\/ul>\n\n