Consentinel Cookie Consent

Changelog

0.2.80

• Added: Consentinel now recognizes two things your web host’s network may add to your pages on its own. Many hosts sit behind Cloudflare, which sets a short-lived __cf_bm cookie for bot protection and may run a bot-detection script from a /cdn-cgi/ address on your own domain. Neither is added by WordPress or by any plugin, and on most managed hosting you cannot switch them off. They are now named in your cookie policy and in the tracker scan instead of appearing as unidentified entries.
• Both are classified as strictly necessary security infrastructure, so nothing about your site’s behavior changes: they are not blocked, not purged, and not counted against your scan result. Consentinel deliberately cannot be configured to block them — the same address also serves the security checks visitors must pass to reach your site, so blocking it could lock real visitors out.

0.2.79

• Hardened: the consent script address supplied by Consentinel Cloud is now checked against the Consentinel domain before your pages will load it. Previously any address the service returned was accepted. If a site ever receives an unexpected address it falls back to the plugin’s own built-in banner and blocking, so visitors always keep a working consent notice.
• Database queries that name the consent log table now use WordPress’s own identifier placeholder, available since WordPress 6.2. Internal change only — the queries do the same thing.
• Changed: Consentinel now requires WordPress 6.8 or newer (it previously declared 6.0). This matches the versions the plugin is actually tested against. WordPress will not offer the update to sites below 6.8, and those sites keep running their current version unaffected.
• Changed: the “a browser reported an unexpected banner script” warning no longer appears as a dashboard notice, and no longer prints the version the browser reported. It now appears only in Tools -> Site Health. That warning is raised by a message any visitor’s browser can send, so it should not be able to interrupt you on every admin screen or put text of its own choosing on it. Warnings about this site’s own files — assets missing or out of date on the server — are unchanged and still appear as notices.
• Tightened how the plugin reads the internal one-time key its own tracker scan uses to fetch your pages. No change to what the scan does or who can run it.
• The Consentinel group in the block inserter now sits with the other plugin groups instead of above WordPress’s own Text, Media and Design groups. The blocks themselves are unchanged.
• Changed: the consent scripts in your page’s are now emitted through WordPress’s own script API instead of being written directly. They load in exactly the same place, in the same order, doing the same thing — this is an internal change for WordPress.org’s coding standards. The plugin now also actively protects those scripts from “defer JavaScript” optimizer plugins, which could previously have delayed the tracker blocker and let trackers run before it.
• The Consentinel Cloud address is now permitted as a redirect target only for the two moments the plugin actually redirects there, rather than for the whole admin session.
• Settings you type into the plugin’s own screens are now cleaned as soon as they are received as well as when they are saved. Formatting in the banner message (bold, links) is preserved exactly as before.

0.2.78

• Changed: a malformed request to the plugin’s internal stale-asset check now gets a standard error response instead of a quiet “ignored.” This only affects deliberately malformed requests and probes — a real browser never sends one, and the plugin doesn’t read this response either way, so there is nothing to notice in normal use.
• Tightened input handling for the geolocation headers that populate the consent log’s jurisdiction field, and for several other server-header reads used for rate limiting and origin checks. A geolocation value outside the small set the plugin understands is now recorded as “unknown” instead of being stored as-is — the same treatment most other unrecognized values already received.
• Escaped output at fourteen more places in the admin screens and banner rendering, closing findings from WordPress.org’s plugin review. No visible change.
• Uninstall now also removes a few small housekeeping options and a short-lived cache entry left behind by earlier releases. Not consent evidence — your consent log and legal-hold setting are unaffected.
• The two admin-side redirects used when connecting to Consentinel Cloud now go through WordPress’s safe-redirect check.
• Fixed a readme installation step that named the plugin’s old, no-longer-used folder name.
• Fixed several strings that could not be translated: the custom block editor labels used the plugin’s pre-rename internal name instead of its current one, and a handful of error messages were never marked as translatable at all. English text was correct throughout; this only affects sites running Consentinel in another language.

0.2.77

• Changed: the Consentinel Cloud banner script is now loaded the way WordPress asks plugins to load scripts. It is still the very first script on the page, which is what makes blocking trackers before they run possible — that has not changed, and it is verified against a real WordPress on every build. What changed is that WordPress itself now writes the tag instead of Consentinel printing it directly.
• New: Consentinel now refuses “defer” and “async” on its own banner script. Some speed-optimization plugins add those to every script on a site. On Consentinel’s script either one would quietly end tracker blocking — the banner would still appear, but trackers that ran first would never have been blocked. They are now stripped, and the plugin’s own optimizer opt-out attributes are re-applied.
• Changed: on WordPress 6.9 and later, page-wide tag gating now uses WordPress’s own output-buffer feature. On older versions the buffer is still opened by the plugin, and is now explicitly closed at the end of the request rather than left for PHP to unwind.
• Changed: the Consentinel admin menu icon is now added as inline stylesheet CSS instead of a style block printed into the page. No visual change.
• Fixed: a link in this readme pointed at a page that no longer exists.

0.2.76

• Fixed: behind a proxy or CDN, a visitor could choose the address recorded against their own consent. Only affects sites with the “Reverse proxy / CDN” setting turned on. The address is now read from the end of the forwarding chain, which the visitor cannot reach, and Cloudflare’s and Akamai’s own headers are read directly. If your origin server is also reachable without going through your CDN, restrict it to your CDN’s addresses — these headers can be set by anyone who can reach the server directly.
• Fixed: installing a second copy of Consentinel could take the whole site down. With two copies active — for example an older manual install alongside one from WordPress.org — the site could fail to load entirely. The second copy now stands aside, the first keeps running, and an admin notice tells you which is which and to remove one.
• New: Consentinel now stands down inside more page builder editors. The banner and tracker blocking are suppressed in Divi, Beaver Builder, Bricks, Oxygen, WPBakery, Brizy, Thrive and SiteOrigin editing canvases, as they already were in Elementor, so embeds like Google Maps preview normally while you design. Only Elementor has been tested on a live site; the others are based on each builder’s documented editor signal.
• New: Tools → Site Health can now tell you if server-side tag gating is not reaching visitors. If you have turned on gating for tags printed directly into the page, a page cache that captures the page before Consentinel runs will serve ungated HTML — and nothing used to detect that.
• Changed: the “unexpected banner script” notice now says a browser reported it, rather than stating it as fact. That report arrives from a public address anyone can post to, so it is a lead worth checking rather than a measurement. It also no longer claims the reported version is older, because it has no way to know.
• Changed: the Site Health row for banner assets now says what it checked. It reads the files on your server; it cannot see what a CDN or a visitor’s browser has cached.

0.2.75

• Fixed: the cookie icon on the floating button was missing. Since 0.2.71 the stylesheet was served from a versioned folder one level deeper than before, so the two images it points at were being requested from the wrong place and never loaded. Nothing else was affected — the banner, the blocking and the consent record all worked normally, the icon simply did not appear.

0.2.74

• Fixed: on some sites consent was not being saved at all. The banner worked, closed normally and applied the visitor’s choice — but on pages served from a cache the record never reached the database, and the plugin reported success anyway. Nothing showed the problem: the consent log simply looked like a site nobody had visited. If your log looks emptier than your traffic, this is why.
• Fixed: a page address could switch off tracker blocking. On sites where WordPress sits behind a proxy on the same server, adding a particular parameter to any page address disabled blocking for that visit. It now requires proof that the request came from Consentinel’s own scanner.
• Changed: “Auto (geolocate)” compliance mode has been withdrawn. It chose opt-in or opt-out from the visitor’s country, but a cached page is stored once and served to everyone — so whoever loaded a page first decided the rule for everyone after them. On a cached site that could put EU visitors on the US opt-out model. Sites set to Auto now use “Block until consent”, which was already the recommended setting. Your stored setting is preserved; nothing was rewritten.
• Changed: the “Do Not Sell” link now shows for every visitor. It used to hide itself for EU/UK visitors, which had the same caching problem in reverse — one EU visitor could remove the link for Californian visitors, who are legally entitled to it.
• New: Consentinel now tells you when consent records are not being saved, or when every record is being stored against the same visitor address (which happens behind a CDN). Both appear as an admin notice and under Tools → Site Health.
• Consent records now carry a bounded action name rather than whatever the browser sent.
• The Scan tab and the readme now state plainly that scripts injected by a CDN — Cloudflare’s Web Analytics, Rocket Loader or Zaraz — cannot be gated by any plugin running on your server.
• Note: pages already sitting in a cache keep the old behaviour until the cache expires or is cleared.

0.2.73

• Listed on WordPress.org under a new address. The plugin is now packaged as “Consentinel Cookie Consent”. The product, the banner and the service are unchanged — only the directory listing address differs, because the shorter name was already taken by a different plugin and WordPress.org cannot reassign an address once it has been used.
• Your settings, your consent records and your cookie are all untouched by this.
• Note for existing installs: this is a separate listing, not an update to an existing install. Sites installed manually can keep running as they are.

0.2.72

• Fixed: updating the plugin could briefly leave returning visitors with no cookie banner. Version 0.2.71 put the version number into the address of the banner’s script and stylesheet, which is what stops an outdated copy being served forever. The side effect was that a page already sitting in someone’s browser cache pointed at the previous version’s address, which no longer existed after an update — so the banner did not load for them.
• Blocking was unaffected in that state: trackers stayed blocked, nothing was transmitted. But the visitor had no way to give or change consent until their browser fetched the page again, which on some sites can be up to a week.
• Updates now keep working copies at the previous few versions’ addresses, so a cached page keeps loading a working banner. This is invisible in normal use and adds about 41 KB to the plugin.

0.2.71

• Consentinel now stays out of the way while you are editing a page in Elementor. The consent banner used to render inside the editor canvas, covering the layout you were working on.
• Embeds also preview correctly while editing. Blocking is paused in the editor, so Google Maps, video embeds and web fonts render as designed instead of appearing blocked — Elementor’s own Google Maps widget was affected.
• Both apply only to the person editing, and only inside the editor. Your visitors are unaffected and a visitor can never trigger this, even by editing the page address — it requires being signed in with permission to edit the site.
• One side effect worth knowing: because trackers load normally in the editor, your own editing sessions may show up in your analytics.
• Fixed: the banner’s “×” could stop closing the banner after an update, with nothing to indicate anything was wrong. Found on two live sites. If something on your site removes query strings from static resources — a common “performance” option — your visitors’ browsers and CDN can keep serving an old copy of the banner script indefinitely, because the address it is cached under never changes. When the old script meets the newer banner, controls on the banner can silently do nothing. One site was caching the old file for up to a year.
• Banner script and stylesheet addresses now include the plugin version, so an update always changes the address and a stale copy cannot be served. This works whether or not query strings are stripped.
• New warning when it happens anyway. If a visitor’s browser reports running an outdated banner script, or this build was packaged without version-stamped files, you get an admin notice naming the versions involved and what to do about it, plus a row in Tools → Site Health. The notice can be dismissed until the next update; Site Health keeps the record either way.
• Note for anyone using that optimization: removing query strings does not measurably improve load times on any current CDN, and it disables update detection for every plugin and theme on the site, not just this one.

0.2.70

• Connecting to Cloud now finishes where the last step actually is. If nothing has been published in Cloud yet, connecting takes you straight to that site’s banner settings there instead of returning you to a WordPress screen that looks unchanged.
• The Cloud tab now says when Cloud has nothing to serve. A site can be connected and verified while Cloud has published no banner — in that state this plugin keeps using its own banner and blocking, which is deliberate, and the tab now says so and links to publishing.
• “Sync config now” reports what it did — synced, nothing published in Cloud yet, or couldn’t reach Cloud. It previously did the right thing silently, which was indistinguishable from a broken button.
• The message shown after connecting no longer claims Cloud is running the site before anything has been published there.

0.2.69

• Housekeeping ahead of the WordPress.org directory listing. No functional changes — the banner, blocking, scanner and Cloud connection all behave exactly as in 0.2.68.
• The plugin’s short description and changelog now fit WordPress.org’s length limits; both were previously long enough to be truncated on the listing page.
• Internal code-standards cleanup for the WordPress.org Plugin Check, including one redundant query argument removed from the page lists used by the scanner and the live-check picker (same pages found either way).

0.2.68

• The “×” on the banner no longer counts as accepting. It previously read “Close and Accept” and granted every category; it now simply closes the banner without recording a choice, so nothing non-essential runs and the banner returns on the next page load. Expect fewer recorded consents and more repeat banners after upgrading — that is the intended behavior, made on legal advice that closing a banner is not clear enough to count as consent.
• “Reject all” is now always shown, at the same visual weight as “Accept all”, and can no longer be turned off. The setting that hid it has been removed.
• “Reject all” added to the preferences dialog, so visitors can refuse everything in one click from there too.

0.2.67

• The tracker scanner’s live check now verifies TLS certificates on production sites (previously verification was always off). Local and development environments — declared via WP_ENVIRONMENT_TYPE — keep working with self-signed certificates.
• Block-editor button labels are now translatable (script translations were never loaded for the editor script).
• Fresh-install defaults are now seeded at the correct point in WordPress’s load sequence, so localized sites get translated banner text out of the box and WP 6.7+ raises no just-in-time translation notice.
• Documented the single uninstall-time request a connected site makes (the legal-hold check) in the External services section, and tightened input unslashing/sanitization throughout to WordPress.org Plugin Check standards.

0.2.66

• The “Powered by Consentinel” link is now off by default. Your visitors see no Consentinel branding unless you turn it on under Settings → Banner. If you are currently showing it, it will disappear on update — switch the toggle back on to keep it. (Sites using the consentinel_show_branding filter are unaffected; the filter still wins.)
• The sliStudios logo on the plugin’s admin screen is now bundled with the plugin instead of being loaded from Amazon S3, so opening the Consentinel screen no longer makes an outbound request to AWS.
• Deleting the plugin now also removes its Consentinel Cloud connection data, including the stored access token. Previously those rows were left behind in the database.

0.2.65

• Refreshed the Consentinel wp-admin workspace with bundled local typefaces, the Consentinel paper/navy/gold visual system, responsive tracker and consent-log tables, and neutral policy chips for the Always / Block until consent / Never tracker modes. Presentation only: settings, labels, scanning, and consent behaviour are unchanged.
• Completed actions now show compact, dismissible Consentinel feedback instead of persistent wp-admin banners. On Consentinel’s own screen, unrelated plugin notices are hidden so the compliance controls and safety notices remain easy to read.

0.2.64

• Fixed: connecting a site to Consentinel Cloud now fetches Cloud’s crawl results straight away. Before this, the Scan tab said “No crawl results have reached this site yet” for up to a day after connecting — even when Cloud already had a finished crawl — because the results were only fetched by the once-a-day background job. Connecting is exactly when you look, so an empty panel there read as “Cloud found nothing”.