Kookies Consent is now in the official WordPress.org plugin directory. After the automatic scan, the human review approved it too, so the plugin now sits where WordPress websites install and update their extensions anyway. For operators, mainly the route changes. Searching, installing and updating now works straight from the WordPress dashboard, without a ZIP file and without a detour. Look for it under the name Kookies Consent. Every download button on this website now leads directly to the plugin page on WordPress.org.
Updates and news
What is new in wpkookies.
Published improvements in plain language, without security-sensitive technical detail.
Version history
The newest entry appears first. Future plugin versions will also be added with their release date.
The first human review round from WordPress.org raised three points about 1.5.70. All three were measured before anything was changed. Two needed a change: the PayPal links took four redirects to arrive — exactly the objection — and now point at PayPal's own legal hub, which takes one. And the readme now describes the connection test in the administration area: who can start it, which hosts it addresses, that every request is meant to be refused rather than loaded, and the one probe type that depends solely on the enforced security policy. Two further reported links were measured and are sound: Yumpu's own server answered three of six requests with an error, and the Mapbox privacy page arrives in 0.3 seconds but weighs 489,124 bytes — exactly the size at which the reviewer's tool ran out of time. The third point concerned a second name prefix and led to a real fault that had nothing to do with names: a redeemed one-time grant was recorded as a hand-built transient row, and WordPress stops clearing such rows as soon as a persistent object cache is running. On those sites they grew without end until the ceiling of 5000 was reached — after which one-time loading was switched off permanently and silently. A marker is now an option row of its own with a sweep of its own on the existing daily event, the ceiling sweeps before it refuses, and an update removes what was left behind. An adversarial multi-agent review found five further faults in exactly this new code before it shipped — all fixed, and 17 mutations without a survivor say so.
WordPress.org refused the 1.5.69 upload: "Tested up to: 7.0 < 7.1". A plugin whose readme falls behind the current WordPress release is not shown in searches. The header now says 7.1 — independently confirmed rather than assumed: the release gate asked api.wordpress.org and got 7.1 back. What makes this value unusual is that it does not go stale because we change something; it goes stale because WordPress ships a release. No gate in this project had ever looked at it, in a file that decides acceptance or rejection. From now on the release check asks for the current WordPress version itself and refuses a release that is behind; when the interface cannot be reached it says so plainly instead of reporting a check that never happened. Nothing about the plugin behaviour changes.
The code scan shipped in 1.5.66 found 17 providers on a real customer site with 36 active plugins — and the browser check met none of them on twelve pages. As one flat list of equal entries the screen demanded seventeen decisions nobody could take, and taking them would have put seventeen services into the visitor consent banner that the site never loads. The measurement decides now: what the browser check really met and blocked stays at the top as a work item, together with the date of the measurement it rests on. Everything else folds into a single line that names its own limits — the check visits a limited number of pages, and what sits behind a form alone it never sees. The attribution runs through the recognised service, never the host name: www.google.com belongs to Google Maps and to reCAPTCHA at the same time, and only the path tells them apart. No green badge without a measurement, and none for a search that was aborted or is out of date. Repaired alongside: the purely diagnostic search button threw away the passed check report of the website, a cache finding vanished after every update instead of only when the question behind it changed, and a service configured through the neighbouring section stayed on as a proposal and then claimed the opposite of what had been measured.
The browser check failed on every installation of 1.5.66 and 1.5.67. It ran to the end and was then refused with "the browser check did not deliver all required page and service evidence" — on a customer site, immediately after updating. The cause was one number kept in two places: 1.5.66 raised the run from five internal pages to twelve, while the server that validates the report kept its own copy at five and rejects any report whose count differs from its own. The number now lives on the server alone; it publishes the value and the browser run reads it, so the two cannot drift apart again. A test compares them across both languages, because nothing else could see this: the browser suite runs against fixtures, the PHP tests build their reports from the server constant and so agree with themselves, and the end-to-end run never starts a real check.
A customer updated, opened the settings screen and was met with a red warning: a cache outside WordPress is serving stored pages, ask your hoster to switch it off. The warning was wrong. It measured whether the home page is stored anywhere at all — true of almost every hosting package, and the harmless case, because the stored page is the anonymous one where everything is blocked regardless. What can actually break consent is a cache that hands that same stored page to a visitor who carries a consent cookie. The check now warms the cache, confirms the page is really being reused, and then asks for it once more with a consent cookie. A cache that answers that from its store is reported; a cache that answers freshly is not, and nothing is shown. When there is something to report, the text says what goes wrong and asks for the thing that helps — letting pages with the consent cookie through to WordPress — instead of demanding that the cache be switched off.
A customer site lost its service list and could not get it back, because the plugin it had been migrated from was gone. Rebuilding it from the browser check reached two providers — that check visits a handful of pages and can only report what those pages happen to load. WPKookies now searches the code that is installed as well: the active plugins, the must-use plugins, the active theme and its parent, for the addresses of the 88 provider domains its catalogue knows. Every provider it finds can be set up with one button. A finding is described for what it is — evidence that this code can contact the provider, not proof that every page loads it. Links and share buttons no longer count as embeddings, the provider lists other consent plugins carry are skipped, and a search that has to stop early says how much of the site it really read instead of reporting an all-clear.
A live, fully migrated installation was wiped by one click on “reset installation”. The reset now lives behind the technical settings instead of between the two blocks the operator works with, and it states the measured loss of that particular site before it can be triggered: how many entries the service list holds, whether a completed migration and a rollback backup are at stake, and how many rows the consent log really has — counted, not assumed. Anything beyond a bare fresh installation takes a second explicit confirmation, enforced by the server. Two further ways to lose the same data are closed: an empty service list is refused instead of stored, and the service editor shows what is stored rather than a filtered view that would delete hidden services on save. On a multisite the uninstall opt-in is read per site. And after a passed check the screen finally says there is nothing to do — but only the server may call a site protected, because the browser check proves one of six checks.
Cache truth instead of cache assumption. Before every browser check the plugin now measures whether the site really serves fresh pages: the identical preview address is loaded twice and must carry two different one-time tokens. A cache caught serving the same stored page twice is named and can be switched off with one click — even a cookie-aware cache loses its free pass once it is proven the cause. A bold warning at the top of the settings screen names the exact blocking cache plugins, eight more page caches are recognized by name, and hoster or CDN caches are identified with concrete header evidence that only the hoster can act on. Every installation has to run the browser check once more.
The browser check now measures what it certifies. The old consent layer keeps blocking third-party content of its own until the switch-over, so “0 unknown connections” was measured with that layer helping. Its hooks are now removed for the check’s own page loads, and the switch-over refuses a report that was not measured that way — every installation has to run the check once more. This release also closes a URL parsing difference between PHP and browsers, narrows shared provider apexes such as cloudflare.com, keeps your consent log when the plugin is deleted unless you ask otherwise, and bounds the policy header across the whole response.
Who owns the advanced-cache.php drop-in is now read from the file instead of inferred from which plugins happen to be active. Only one plugin can own it, and not necessarily one that is still running: on a live site the file belonged to a deactivated Cache Enabler while another cache was active, and the old inference declared that site cache-free while a dead plugin’s drop-in ran on every request. Anything that cannot be attributed now blocks the check, because it cannot be shown to be harmless.
A page cache that blocks the browser check is now switched off with one button inside the guided flow. Until now the run named the offending plugin and sent the operator into the plugin list — but the people this plugin is built for cannot know which of their plugins is a full-page cache. wpkookies remembers exactly what it switched off and can switch it back on. Cookie-aware caches such as Surge are allowed and are never touched.
The advertised PHP requirement is now the truth. Every declaration said PHP 8.1, but three classes have needed 8.2 all along — on an 8.1 host the plugin stopped with a parse error instead of a useful message. A new release gate measures the requirement against the shipped code, so the two cannot drift apart again.
The browser check now derives a probe path from the service it is actually testing, not from the first member of that service’s consent group. On a shared provider origin the group’s first entry is usually a different service, so the probe belonged to nobody and came back as an unknown finding the check had invented itself.
The browser check no longer probes Google Ads on a path that service does not own. On a Google country host it owns exactly its two marketing endpoints, so the synthetic probes came back as unknown findings the check had invented itself.
The browser check now binds the applied Borlabs import to the configuration it is about to measure. Any legitimate change to the service list since the import otherwise let the run execute for ninety seconds and then be refused, leaving no way to finish the takeover.
Completes the automatic repair: it changes the service list, which broke the binding between a running Borlabs takeover and its browser evidence, so every later run was rejected. The upgrade path now rebinds the takeover.
Fixes the automatic repair shipped one version earlier: the repair was correct, but the data migration version was not raised, so it never ran on an existing installation. The too broad Google rule is now really narrowed on update.
A hardening release after an adversarial review of the two previous versions. Two findings could take a running site down: an oversized security policy made servers answer the whole page with an error, and the late re-assertion recomputed the policy instead of repeating the one that was sent, so two different own policies could block consented content. Setting up a Google endpoint now carries the measured host instead of the whole domain, which had tied advertising, maps and reCAPTCHA into a single consent decision. Existing installations are repaired automatically.
A finding no longer falls between two matchers: the browser reported www.google.com/ccm/collect as unknown while the findings list considered it already configured, so the run named a number and offered nothing to act on. That address — Google’s consent mode — is now recognised as Google Ads with the usual one-click setup. And when the WordPress session expires during a check, the run says so instead of sending you off to clear caches.
A security plugin could silently replace the enforced security policy of wpkookies — on such websites the import() loading path was left unprotected. The policy is now re-asserted after every other plugin and takes its place beside the foreign one instead of displacing it. A report-only policy no longer counts as blocking evidence, and when the policy is missing entirely the check names the cause instead of listing eleven follow-on errors.
A blocked analytics or tag-manager script no longer produces a consent box. It has no place on the page, so the box ended up above logo and navigation and pushed the whole site down. Such scripts are now blocked silently; the decision stays in the banner. Visible embeds keep their placeholder where the content stands.
The catalog now recognises 36 provider services: Microsoft Advertising joins it, and Hotjar, Pinterest and TikTok gain the addresses they were missing — existing installations included. Anonymous CDN hosts deliberately stay without an entry, because nobody can state their provider or purpose. The list on the homepage is generated from the shipping catalog, so it cannot go stale.
Hardening from the audit: the proof store can no longer be locked out by a flood, one-time grants can no longer flood the database, and a third-party filter no longer becomes permanent configuration. Percent-encoded addresses survive the check tool, and a stopped migration run no longer looks like a running one.
Two security fixes: a rollback taken before the cutover switched the public protection off, and WebSocket connections were never blocked although the documentation promised it. Matomo Cloud is no longer configured as self-hosted with the wrong provider. The check area now retracts a green “verified” the moment a run fails and names the next step right above the button that performs it.
The Google Signals audience beacon of Google Analytics 4 is now recognised as the standard service “Google Ads and DoubleClick” and can be set up with one click — including the country-specific Google host. The finding also explains that the beacon is a GA4 property setting: operators who do not want remarketing simply disable Google Signals in Google Analytics.
Findings from the browser test now appear on the running page without a reload, and recognised but never configured services — a Tag Manager snippet, say — become findings too, with the familiar one-click setup. Every run records what it actually saw; a failed hand-off no longer claims the findings are available.
Leftover database rows no longer count as an installation: Borlabs options and tables survive an uninstall but were reported as “Borlabs found” — on sites whose plugin list does not contain Borlabs at all. Residue is now named as residue, and the guided takeover stays hidden there.
When the browser test finds an external address with no configured service, the finding is kept and can be set up right there — with one button for recognised providers, otherwise through a small form that names every missing mandatory detail. The guided Borlabs takeover now appears only where there is actually something to take over.
A migration run that stopped on an error no longer presents itself as a running one: instead of the spinner and “the operation continues” it now says that it has stopped. The public runtime switch is also read consistently — with the setting missing, the frontend and Guardian used to describe the site differently.
The second browser-test run is now explained. When the plugin configures an unambiguously recognised service itself, the configuration changes and the earlier measurement no longer applies — so the test measures exactly one more time. The reason now comes from the server, survives the page reload and names the service that was added. The test mechanics are unchanged.
The eval compatibility guard now also recognises Smart Slider 3 Pro, which ships as a separate package. On those sites the guard was never loaded, so Smart Slider’s harmless empty eval call made the protection test fail with an unsafe-eval message. The message now names the affected page and script; “unsafe-eval” stays forbidden.
The narrowly scoped eval compatibility guard now loads only when Smart Slider is actually active. Other sites and automated browser checks are no longer intercepted; executable eval code remains blocked by the strict CSP.
The compatibility guard now rejects non-empty eval input itself, never executes it and records the attempt for Guardian. Only Smart Slider’s exact empty no-op remains accepted.
The exact-empty-eval guard now remains active for the complete page lifetime because Smart Slider runs its empty callbacks after DOMContentLoaded. Non-empty code still delegates to the native function and remains blocked by CSP.
The narrowly scoped empty-eval guard now runs before all frontend scripts. It therefore also covers libraries that capture eval during startup, while non-empty code execution remains blocked by CSP.
Empty eval calls are temporarily treated as the no-op they represent during early page startup. Smart Slider empty callbacks no longer violate CSP, while non-empty code execution remains forbidden and detectable.
The CSP-safe Smart Slider correction now also covers initializers printed directly in the WordPress head. Its narrowly scoped output buffer is fully closed during the same wp_head action.
Smart Slider empty callbacks are now made CSP-safe without allowing unsafe-eval. The Guardian also detects remaining forbidden eval attempts and stops instead of storing a misleading green report.
The WordPress.org review findings have been resolved: rendered shortcode output is sanitized, output buffering is managed by WordPress, request cookie names are strictly validated, and optional external providers are disclosed in the plugin documentation.
Guardian report validation now expands each concrete test target through the actual configured technical consent group. Services linked indirectly through another shared provider domain are therefore checked together correctly; incomplete groups remain invalid.
Guardian report validation now uses the same complete consent groups as the frontend. Technically coupled services with overlapping provider domains, such as Google Maps and reCAPTCHA, no longer cause a correct browser report to be rejected; incomplete groups remain blocked.
The Guardian now evaluates banner visibility only during the real first visit, not again after an intentionally saved rejection. All service-specific blocking and browser-loading-path checks remain strict.
Older guided Borlabs migrations are now repaired even when their internal import-profile marker is missing. The repair requires explicit Borlabs provenance and an unambiguous catalog match; custom and ambiguous services remain unchanged.
Data repairs now have their own one-time migration version. Existing installations therefore receive security-relevant service corrections even when their database schema is already current, including the missing Google Maps runtime origins after a 1.5.27 migration.
Guided Borlabs migrations now add provider-specific runtime origins to uniquely recognized imported services. Existing standard services are repaired safely, so Google Maps receives maps.googleapis.com without changing custom operator rules.
The browser test now retries temporary HTTP 429/503 blocks from security plugins automatically, avoids artificial local request bursts, and performs fewer redundant page loads.
Doctify review widgets and their scripts are now recognized automatically as one external-media service, prepared with complete provider information, and blocked until consent.
The browser test now recognizes an active Surge page cache as a supported cookie-aware cache and checks the website while caching remains enabled. Unknown cache drop-ins and unsupported cache plugins remain safely blocked.
Self-hosted Matomo that only appears when a theme or plugin renders the protected preview is now identified automatically from its unambiguous script path. The detected host is added as the website operator’s statistics service and the test restarts; every other unknown address remains blocked.
Active, unambiguously recognised Borlabs standard services are now transferred automatically. WordPress users no longer need to confirm technical provider or domain tables; only unknown custom integrations trigger a clear question.
The automatic browser test now shows every step, the service being checked, elapsed time and a continuously calculated remaining time. Repeated page loads are explained and no longer flicker visibly. After a successful migration test, the assistant advances reliably to cutover instead of restarting the test.
During Borlabs migration, embedded content on shared provider domains is now identified by its URL path. For example, www.google.com/maps/embed is imported automatically as Google Maps with the local catalog metadata, while ambiguous generic Google URLs remain held for review.
The browser test no longer treats the bare WP_CACHE flag as proof of an active page cache. A real advanced-cache.php drop-in and known active cache plugins remain blocking, while the test measures the website’s actual response and protection behaviour.
A confirmed full reset now verifies cleanup, creates a new installation identity and purges available caches. Shared data remains protected when legacy and directory packages coexist, while network activation initializes existing and new multisite sites. PageSpeed markers and no-transform improve gatekeeper compatibility without promising support for every optimizer configuration.
Deleting the plugin removes all WPKookies data. Retained legacy data can be reset directly to a fresh installation after explicit confirmation.
The security-critical gatekeeper is excluded from PageSpeed rewriting and script deferral, without weakening the strict security policy with unsafe-eval.
The Borlabs migration recognizes known providers such as SoundCloud from generic import data, avoids duplicate consent requests, and verifies grants without artificial third-party calls.
Cookie-aware page caches such as Surge are supported, so each consent state receives its own correct cached variant.
The browser-test button now completes the safe configuration step automatically when it was already reviewed, then starts the test.
Migration warnings for imported code are now clearly marked as non-blocking, while unsafe cookie cleanup is rejected before execution.
Yumpu embeds discovered directly in page content now receive the same provider information as configured services.
Yumpu migration now receives its retention information even when the source export leaves that field empty.
Yumpu is now recognised as a service during migration and prepared with provider and privacy information.
The automatic test now explains clearly when WordPress returns an HTML error page instead of the expected JSON response.
The WordPress directory package is now verified more strictly before release. Migration recovery also works reliably on staging and test sites accessed through an IP address.
Initial setup is now clearer, related services are grouped consistently, and known providers are recognised more reliably. Automated privacy checks accompany the configuration up to approval.
WPKookies is now available in eight European languages. Visitors see consent and privacy settings in the website language, while operators can translate administration and service information.
Permissions for known content such as YouTube can be granted once or across all pages. The current choice can be reviewed, withdrawn and downloaded as a readable file.
Protected preview and automatic website testing now work faster and more reliably on larger WordPress websites.
Known video and social media content is recognised more clearly and can be enabled specifically. The settings control now uses the compact WPKookies logo.
The automatic website test in the migration assistant now works more reliably in additional WordPress environments.
Websites using only necessary services can complete the guided migration. Unsuitable export files are explained more clearly.
The installation package was improved for reliable detection and activation on WordPress servers.
Input validation is stricter and the automated quality checks have been expanded.
Control of external content, one-time permissions and the guided migration process were substantially expanded.
Consent changes and their automatic checks were further strengthened.
After a successful website test, cutover can be completed without interruption. Missing stages are named clearly.
Delayed content can be enabled reliably again after a rejection.
Rejected external content can be permitted directly in settings without reloading the page.
Related services are grouped cleanly during migration and are not shown twice.
External embeds in page content are also detected during migration and suggested for review.
Migration from current Borlabs installations was extended and limited more clearly to services actually in use.
Migration focuses more accurately on required services and avoids irrelevant entries.
Installed Borlabs versions are detected more reliably. Cutover remains safely locked when data is incomplete.
A guided migration assistant introduced review, automated website testing, cutover and rollback.
Updated controls are delivered reliably even when website caches are active.
The settings control works more robustly with different WordPress themes and optimisations.
Access to privacy settings was further stabilised.
The settings dialog can restore itself after changes made by themes or caches.
Guided migration is named more clearly. Plugin removal was improved for additional hosting environments.
Administration was redesigned as a clear migration assistant with five guided stages.
First release with local consent management, individual service choice, content blocking, withdrawal and migration tools.
Download the current version
Kookies Consent is available free of charge in the official WordPress plugin directory.