WorkMore Cookie Crumb – Cookie Consent Banner

It is free, with no limit: no account to open, no page view quota, no visitor count that stops the banner. Everything this plugin does runs on your own site. A separate Pro add-on exists for those who want more (see "Pro add-on" above); nothing in this plugin is locked without it.

No plugin can promise that by itself — compliance depends on what your site does, the law that applies to it and how you set things up. What this plugin gives you are the tools those laws ask for: consent before tracking (opt-in), a "Reject all" as easy as "Accept all", consent by category, a way to change the answer at any time, and a record of each answer. It is not legal advice.

Yes. An embedded YouTube video, Google Map or Facebook post does not load before the visitor allows its category; a placeholder with a button stands in its place, and the button allows it. Any other embed can be held back by a rule with a piece of its address.

Yes. It recognises WooCommerce's own cookies (cart, session) and its order attribution (sbjs_*), the cookie scan reads a shop's own pages, and the WP Consent API tells WooCommerce what the visitor allowed.

Yes. The server sends the same page to every visitor and never reads the visitor's answer; what runs is decided in the browser. Publishing the banner asks the cache plugins and hosts the plugin knows to clear their page cache (WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super Cache, WP Fastest Cache, Cache Enabler, WP-Optimize, Autoptimize, Breeze, Hummingbird, Comet Cache, SiteGround Optimizer, Nginx Helper, WP Engine, Pantheon); for any other cache, clear it after publishing. Plugins that combine, defer or delay scripts are asked — by marks on its tag that Autoptimize, LiteSpeed Cache, WP Rocket and Cloudflare's Rocket Loader read — to leave the plugin's first script where it is: it has to run before every other script of the page.

Yes. Before a visitor answers, the plugin sets the Consent Mode v2 signals to "denied" — the advertising signals follow your marketing category, the analytics signal your analytics category — and updates them with each answer; an event named wmcc_consent is pushed to the data layer as well. You choose how Tag Manager itself is treated: listed under a category, the container waits for that category like any other script; left out of the list, it loads and its tags follow the Consent Mode signals.

Google Analytics, Google Tag Manager, Google Ads, YouTube, Google Maps, Meta Pixel and Facebook embeds, and the cookies WordPress and WooCommerce set themselves. A recognised service gets its category suggested, and its cookies listed with what they are for. Anything else the scan finds is shown as not known: you choose its category. A script is held back by a rule that looks for a piece of its address, so any script can be listed.

When you press "Scan the site", the screen opens a sample of your pages — the front page, the newest entry of each kind of content, a shop's own pages, and addresses you add — in your own browser, served the way a visitor who is not logged in gets them. The server notes the cookies it sets and what stands in each page's markup; a small script in the page notes the cookies scripts set and everything the page loads. Nothing is sent to an outside service, and nothing is added to your cookie list until you choose it. A scan cannot see what loads only after a click or a purchase, what an ad blocker in your browser stops, or the cookies another site keeps on its own domain; those are listed where the service is known. While it runs, your pages' own trackers run once in your browser, as they would for a visitor who allowed everything — in a browser that is logged in to your site, and including trackers your site leaves out for administrators.

Scripts and embedded frames always can, and images and loading hints when they stand in the page's markup. What a script that is already running sends by itself or writes into the page as markup, and style sheets and fonts loaded from another site, cannot be held back by a rule: hold back the script that does it, or serve the file from your own site. After you publish, the scan lists whatever still reaches another site before a visitor answers, and says for each whether a rule can hold it.

By default a small round button stays in a corner of every page and opens the cookie settings window. Instead of it, or as well, any link to #cookie-settings opens the window — in a menu, a footer or a page — and so does the [wmcc_settings] shortcode. Withdrawing consent deletes the listed cookies your site set and loads the page again without the scripts. Cookies another site keeps on its own domain, and cookies no script can read, cannot be deleted from a page.

As little as it takes to be a record: a random consent ID (kept in the visitor's own consent cookie, and shown to them in the cookie settings window), the time, the answer and the categories it allowed, the version and language of the banner, the address of the page without its query string, the browser's name and major version with the name of the operating system, and the network part of the IP address — the last part of the address is never stored. A record is not linked to a user account, and is deleted after 90 days. Settings → Privacy → Policy guide has a paragraph you can use in your privacy policy.

A page reports that it was shown, with one small request to your own site that carries no cookie and nothing about the visitor; the site adds one to that day's number. A busy site (more than 2,500 page views a day) counts a sample instead — one page view in so many, each counted for that many — so the counting stays light however much traffic there is. A developer can switch page view counting off with the wmcc_count_pageviews filter.

Yes, on purpose only. The banner lives in a shadow root under <div id="wmcc-root">, so your theme's styles do not change it by accident. What your style sheet can set are these custom properties on #wmcc-root — --wmcc-bg, --wmcc-text, --wmcc-muted, --wmcc-line, --wmcc-font-size, --wmcc-radius, --wmcc-button-radius — and rules for its named parts, written #wmcc-root::part(name): banner, text, title, body, policy, actions, button (with accept, reject, settings, save, and in-banner or in-window), close, credit, credit-icon, overlay, window, window-head, window-title, window-body, window-foot, intro, category, category-name, switch, consent-id, reopen, reopen-icon. For example: #wmcc-root::part(accept) { background: #0a7d3c; color: #fff; }. Keeping the text readable on your colors is then yours to check, and a font or picture such a rule loads from another site reaches that site before the visitor answers.

In any you add: each language has its own words, and the banner follows the language of the page. Words are ready in English and Thai; for another language you start from the English ones and write your own. The plugin's own screen is in English, with translations served by WordPress.org as they are completed.

Yes. Each site of a network has its own banner, cookie list and consent log, managed by that site's administrators.

No. The banner, its script and the cookie list are served by your own site, answers and page views are recorded in your own database, and the plugin makes no request to any other server. It adds no credit or link to your pages unless you switch on the "Powered by WorkMore Cookie Crumb" line yourself (Banner design → Text; off by default). On its screen, the only link to our website is on the "Upgrade to Pro" tab, and it opens only when you click it. The section "External services" below says what the names of other companies' services in the plugin are for.

Deactivating takes the banner off and stops holding scripts back at once: nothing in your content was changed, so there is nothing to undo. It deletes nothing. Uninstalling removes the consent log, the statistics and the settings only if you asked for it under Settings → Cookie Crumb → Settings, where the switch is off by default — a consent log is a record you may be asked for.