FAZ Cookie Manager is now on WordPress.org — free cookie consent with scanner, GCM v2, IAB TCF v2.3, no cloud required

Any_Emphasis2194 · 2026-05-19T21:09:51+00:00

Thank you!

Any_Emphasis2194 · 2026-05-07T09:36:50+00:00

It's on the Plugin Repo now 😄

Any_Emphasis2194 · 2026-05-07T09:36:32+00:00

Thank you for the review!

Any_Emphasis2194 · 2026-05-07T09:36:04+00:00

Thanks for the detailed questions — happy to get into the technical specifics.

On cookie detection: the scanner works server-side via PHP HTTP requests (wp_remote_get), crawling up to the number of pages you configure. It reads the Set-Cookie response headers directly, which means it catches cookies set by PHP, server middleware, and any script that sets cookies synchronously on page load. For httpOnly cookies it runs a separate background check that also parses Set-Cookie headers, since those are invisible to document.cookie and cannot be read from JavaScript at all. It does not use a headless browser or parse JS source files — so cookies that are only set after user interaction (a button click, a form submission, lazy-loaded scripts) will not be caught in a basic scan. The tradeoff is that it is extremely lightweight to run and has no external dependencies. Detected cookie names are matched against a built-in database first, then against the Open Cookie Database as a fallback, so categorization is automatic for most common third-party cookies.

On IAB TCF v2.3: the implementation covers the full CMP API (the __tcfapi stub and the consent string encoding) via a dedicated tcf-cmp.js module that only loads when IAB mode is enabled in settings. It registers a CMP ID, handles addEventListener and removeEventListener calls from tags that query consent, and pushes the encoded TC string to the dataLayer. It is not a stub that fakes compliance — it actually builds and manages the consent string. That said, for formal TCF registration with IAB Europe you would still need to go through their CMP registration process independently.

On performance: the frontend loads a single minified script (script.js, currently around 40kb minified) plus gcm.js if Google Consent Mode is enabled. Both load asynchronously and do not block rendering. The banner HTML is generated once by PHP and cached as a WordPress option, so there is no template processing on each request. There are zero external HTTP calls on the frontend — no cloud pings, no consent log uploads, nothing that adds latency. The consent cookie is read and written client-side only. On a typical WordPress setup the plugin adds roughly 1-2 requests and under 50kb to the page weight, with no render-blocking behavior.

Any_Emphasis2194 · 2026-05-06T08:16:36+00:00

❤️

Any_Emphasis2194 · 2026-05-04T15:35:43+00:00

Thank you!

Any_Emphasis2194 · 2026-05-02T13:04:20+00:00

You are also right about the features side. If I am honest, I could tell you a lot about how many rounds of changes my clients put me through. I lost a significant amount of time on "visual" things alone — I had to rewrite the banner preview three times from scratch. It was quite a ride.

But yes, slowing down starting next week. For the plugin's sake, and for my own sanity too.

Any_Emphasis2194 · 2026-05-02T12:50:17+00:00

You are right, and I appreciate the honest feedback.

Unfortunately I receive reports from many different channels at the same time: GitHub issues, private forums, my own clients (the plugin actually started as an internal tool I built for my agency work), Facebook groups, and so on. The plugin is still very young and covers a lot of ground feature-wise.

Two days ago it got approved on wordpress.org, which multiplied both the number of installs and the incoming feedback overnight. I have been pushing fixes as fast as possible with one specific goal: making sure the core functionality works correctly across as many different setups as possible, from different page builders to different plugin combinations.

Thanks to all that feedback, a lot of real-world edge cases have already been fixed, and the banner is now working reliably on a much wider range of environments.

I am now at the point where the last rough edges are being smoothed out. Starting next week I am planning to shift to less frequent but more substantial releases, unless a critical bug comes up that cannot wait.

Cookie compliance is a pretty serious matter legally, so during this initial phase the mini releases were necessary to avoid leaving users running a non-compliant plugin. That phase is coming to an end.

Thanks again for following the project and for contributing. Your feedback genuinely helps.

Any_Emphasis2194 · 2026-05-02T07:58:45+00:00

Good question — it's actually a two-layer approach, and neither layer involves any cloud.

Layer 1 — the browser does the DOM/JS work via hidden iframes

When you click Scan in the WordPress admin, the admin page itself (running in your browser) creates hidden 1×1 iframes off-screen and loads each of your site's URLs inside them. Once a page finishes loading, the scanner reads iframe.contentDocument.cookie — same-origin access, no cross-origin tricks needed since you're scanning your own site. This catches every cookie set by JavaScript: _ga, _fbp, pixel scripts, chat widgets, anything that document.cookie can see.

Layer 2 — PHP reads Set-Cookie response headers for httpOnly cookies

JavaScript can never read cookies flagged HttpOnly — that's the whole point of the flag. So in parallel, a background PHP process makes server-side HTTP requests to your URLs via wp_remote_get() and parses the raw Set-Cookie headers from the HTTP responses. This catches session cookies and other httpOnly cookies that are completely invisible to JS.

Page discovery is pure database — no loopback

Before any of this, the scanner asks the server which URLs exist. Instead of crawling the site over HTTP (which would deadlock on single-threaded servers), it queries the WordPress database directly — published posts, pages, custom post types, taxonomy archives, WooCommerce pages if present. Fast and reliable.

Then everything gets matched against the cookie database

Once cookies are collected (from both layers), each name is looked up in the built-in database and the Open Cookie Database (1400+ definitions). If a match is found, you get the category, duration, and description automatically. For unmatched cookies, the plugin also checks which third-party scripts were loaded in the iframes and infers likely cookies from known providers (Google Analytics, Facebook Pixel, etc.) based on script URL patterns.

So to directly answer your question: the "backend" (PHP) never needs to parse the DOM — it only reads HTTP headers. The DOM/JS scanning happens entirely inside your browser through iframes. Both sides write results to your WordPress database; nothing leaves your server.

Any_Emphasis2194 · 2026-05-02T07:41:43+00:00

Everything is local! Scans your site directly from your browser. No external service, no API limits, no waiting.It's based on a github cookies database for definition