Title: Consentinel Cookie Consent
Author: sliStudios Web Development
Published: September 2, 2026
Last modified: September 2, 2026
---
Search plugins
# Consentinel Cookie Consent
By [sliStudios Web Development](https://profiles.wordpress.org/slistudios/)
[Download](https://downloads.wordpress.org/plugin/consentinel-cookie-consent.0.2.80.zip)
* [Details](https://wordpress.org/plugins/consentinel-cookie-consent/#description)
* [Reviews](https://wordpress.org/plugins/consentinel-cookie-consent/#reviews)
* [Installation](https://wordpress.org/plugins/consentinel-cookie-consent/#installation)
* [Development](https://wordpress.org/plugins/consentinel-cookie-consent/#developers)
[Support](https://wordpress.org/support/plugin/consentinel-cookie-consent/)
## Description
Consentinel is built US-first. California’s Invasion of Privacy Act (CIPA) is driving
a wave of lawsuits against American companies whose sites load pixels, session-replay,
and analytics that transmit visitor data _before_ the visitor consents. The strongest
defense is prior consent, technically enforced before any data leaves the browser—
which is exactly what Consentinel does. CCPA/CPRA and EU GDPR are supported secondarily.
* **CIPA-safe blocking mode.** “Block until consent — everyone” stops every non-
essential tracker (analytics, ad pixels, session replay) from firing until the
visitor consents — the enforced-before-transmission posture courts look for.
Per-tracker Always / Block-until-consent / Never modes are enforced at runtime
by intercepting each tracker’s network domains.
* **Tracker scanner with CIPA risk flags.** Crawls your active theme and plugins
for known third-party tags (Google Analytics, Meta Pixel, Hotjar, Clarity, HubSpot,
LinkedIn, TikTok, Pinterest, X, YouTube, Vimeo, Google Maps, Fonts, reCAPTCHA,
Intercom, Segment, Mixpanel, Amplitude, Matomo, Cloudflare) and flags the session-
replay tools and ad pixels that CIPA plaintiffs target.
* **One posture for every visitor.** Block until consent (the CIPA-safe default)
or CCPA opt-out — chosen by you, applied to everyone, and unaffected by page
caching. GPC honored as a deemed CCPA/CPRA opt-out.
* **Proof of consent.** A hashed, IP-truncated log is stored server-side so you
can demonstrate prior consent — the primary evidence in a CIPA/CCPA defense (
also satisfies GDPR Art. 7(1)).
* **No external dependencies.** ~20KB JS + CSS, vanilla, no jQuery.
### External services
**Consentinel works entirely on your own server by default. Out of the box it makes
no outbound connection to us at all.** Everything below happens only if you choose
to connect the site to Consentinel Cloud, our optional hosted companion service,
from the plugin’s Cloud tab.
The plugin’s own tracker scanner fetches pages **from your own site only** — it
refuses any URL whose host does not match your Site Address — and the consent log
is written to your own database. Neither leaves your server.
#### What Consentinel Cloud is
Consentinel Cloud (https://consentinel.co) is a hosted service, run by sliStudios
Web Development, that crawls your site in a real browser to measure which trackers
fire before consent, and can centrally manage this plugin’s blocking configuration
across several sites. Using it requires a Consentinel Cloud account. It is entirely
optional; the plugin is fully functional without it.
* Terms of Service: https://app.consentinel.co/legal/terms-of-service
* Privacy Policy: https://app.consentinel.co/legal/privacy-policy
* Data Processing Addendum: https://app.consentinel.co/legal/dpa
#### When you connect a site (you initiate this from the Cloud tab)
Your browser is redirected to `https://app.consentinel.co/connect`, sending your**
site’s domain name**, a one-time PKCE code challenge, and a return address on your
own admin. To prove you control the domain, Consentinel Cloud then fetches a one-
time challenge value from your site at `/wp-json/consentinel/v1/challenge`.
Your site then contacts `https://app.consentinel.co` directly:
* `POST /api/bridge/exchange` — sends the one-time authorization code, its PKCE
verifier, and **this plugin’s version number**. Receives a site-scoped access
token and your configuration.
* `POST /api/bridge/verify` — sends the access token to confirm the pairing.
#### While a site stays connected
Once a day, and when you click “Sync config now”, your site sends its access token
to:
* `GET /api/bridge/config` — retrieves the blocking configuration you set in Consentinel
Cloud.
* `GET /api/bridge/scan-summary` — retrieves the summary of Cloud’s most recent
crawl, for display in the plugin.
* `GET /api/bridge/site-status` — retrieves the connection status shown on the
Cloud tab.
**No visitor data, page content, or consent records are sent by any of these requests.**
They carry the access token and nothing else.
Consentinel Cloud can also notify your site that its configuration changed, by calling`
POST /wp-json/consentinel/v1/config-poke` on your site. That notification carries
no configuration itself — it only prompts your site to make the `GET /api/bridge/
config` request above, so configuration always travels in the direction your site
asked for it. Both this route and the `/challenge` route above are added by this
plugin and answer only while a site is connected.
#### What your visitors’ browsers load when a site is connected and published
Consentinel Cloud serves the consent banner and blocking engine as a single JavaScript
file, and the plugin loads it into your pages from `https://api.consentinel.co`.
That script runs in your visitors’ browsers, and when a visitor makes a consent
choice it records that choice to Consentinel Cloud, including a **truncated and
hashed** form of their IP address and user agent (never the raw values), the choice
made, and the time. This is how Consentinel Cloud provides a consent record you
can rely on as proof of consent. While a site is connected, the plugin’s own local
banner and consent log are switched off, so a visitor sees one banner and their
choice is recorded in one place.
Disconnect at any time from the Cloud tab: the plugin stops contacting Consentinel
Cloud, removes the remote script, and restores its own local banner and consent
log.
#### One request during uninstall (connected sites only)
If you delete the plugin while a site is still connected **and** you have opted
in to deleting the consent log, the plugin makes one final request to `GET /api/
bridge/site-status` (carrying the access token and nothing else) to ask whether
Consentinel Cloud has a legal hold recorded for the site. A legal hold means someone
is legally obliged to preserve that consent evidence, so the plugin refuses to destroy
it — and if Cloud cannot be reached, it also refuses, erring toward preservation.
Disconnected sites, and uninstalls without the delete-data opt-in, make no request
at all.
#### Links, not connections
**Consentinel shows your visitors no branding unless you switch it on.** The “Powered
by Consentinel” link is OFF by default; turn it on under Settings Banner “Powered
by Consentinel”.
With it on, the link on the banner and the shield icon in the preferences dialog
point to https://consentinel.co and carry a campaign tag identifying which element
was clicked and your site’s domain. These are ordinary links — nothing is sent unless
a visitor clicks one. With it off, no link is rendered at all; the preferences dialog
keeps its shield icon, it simply stops being a link. The `consentinel_show_branding`
filter still overrides the setting in either direction.
### Integrating your trackers
Replace this:
```
```
with:
```
```
When the visitor consents to analytics, Consentinel rewrites the tag into a real
script.
### Shortcodes
* `[consentinel_preferences]` — re-open the preferences modal.
* `[consentinel_do_not_sell]` — CCPA Do-Not-Sell-or-Share link. Renders for every
visitor: it was previously hidden for EEA/UK visitors, but a page cache serves
one copy of a page to everyone, so hiding it stripped the control from Californian
visitors too.
* `[consentinel_withdraw label="Withdraw consent"]` — one-click withdrawal of all
non-essential consent.
### Global Privacy Control (GPC)
When the visitor’s browser sends `Sec-GPC: 1` (or `navigator.globalPrivacyControl
=== true`), Consentinel treats it as a deemed opt-out under CPRA §1798.135(b)(1):
all non-essential categories are forced off, the banner is suppressed, and the consent
log records `method = "gpc"`. If a client somehow posts a non-opt-out choice while
the GPC header is set, the server rewrites it and logs `method = "gpc-override"`.
## Screenshots
[⌊The consent banner, with Accept all, Decline and Preferences, fully themeable
to your palette.⌉⌊The consent banner, with Accept all, Decline and Preferences,
fully themeable to your palette.⌉[
The consent banner, with Accept all, Decline and Preferences, fully themeable to
your palette.
[⌊The preferences dialog, showing the trackers actually detected on your site grouped
by category.⌉⌊The preferences dialog, showing the trackers actually detected on
your site grouped by category.⌉[
The preferences dialog, showing the trackers actually detected on your site grouped
by category.
[⌊Tracker scan results — what was found in your theme and plugins, which trackers
actually load, and the CIPA risk of each.⌉⌊Tracker scan results — what was found
in your theme and plugins, which trackers actually load, and the CIPA risk of each
.⌉[
Tracker scan results — what was found in your theme and plugins, which trackers
actually load, and the CIPA risk of each.
[⌊Per-tracker blocking modes: Always block, Block until consent, or Never block.⌉⌊
Per-tracker blocking modes: Always block, Block until consent, or Never block.⌉[
Per-tracker blocking modes: Always block, Block until consent, or Never block.
[⌊The consent log, with hashed IP, the choice made, and CSV export (which also includes
a hashed user agent).⌉⌊The consent log, with hashed IP, the choice made, and CSV
export (which also includes a hashed user agent).⌉[
The consent log, with hashed IP, the choice made, and CSV export (which also includes
a hashed user agent).
[⌊Consent mode and banner settings, including the CIPA-safe default.⌉⌊Consent mode
and banner settings, including the CIPA-safe default.⌉[
Consent mode and banner settings, including the CIPA-safe default.
## Blocks
This plugin provides 3 blocks.
* Cookie Preferences Link
* Do Not Sell or Share Link
* Withdraw Cookie Consent
## Installation
1. Upload the `consentinel-cookie-consent` folder to `/wp-content/plugins/`, or install
the plugin through the **Plugins Add New** screen.
2. Activate **Consentinel** through the **Plugins** screen.
3. Go to **Consentinel Consent mode & Banner**. The default is **Block until consent—
everyone**, which is the CIPA-safe posture; leave it unless you have a reason to
change it.
4. Confirm **Block trackers** is on. With it off, nothing is blocked and the per-tracker
modes are ignored — the plugin says so prominently, but it is worth checking.
5. Open **Tracker scan results** and run **Scan + Verify**. This finds known trackers
in your active theme and plugins and confirms which of them actually load on your
pages.
6. Review each tracker’s blocking mode. Test on a staging site first if you can: blocking
a functional embed such as a map, font, or reCAPTCHA changes how those parts of
your site behave.
Connecting to Consentinel Cloud is optional and is not part of installation. See**
External services** above.
## FAQ
### Can Consentinel block scripts added by Cloudflare or my host?
Not the fetch, no. Consentinel gates what WordPress renders, and it runs
before
anything else on the page. A script injected after WordPress finishes — Cloudflare’s/
cdn-cgi/ features such as Web Analytics, Rocket Loader or Zaraz, or an equivalent
from your host or firewall — is added to the response on its way to the visitor,
so no plugin running on your server can see or gate it.
Consentinel still blocks what such a script transmits once it runs, because it
patches the browser’s network APIs before any of it executes. But it cannot stop
the browser fetching the file. If you need pre-consent silence there, turn the feature
off at the CDN.
### Does this work without a Consentinel Cloud account?
Yes, completely. The banner, the blocking engine, the tracker scanner, the consent
log, Global Privacy Control and Google Consent Mode all run on your own server with
no account and no outbound connection to us.
### Will this make my site compliant?
No plugin can do that, and any that claims otherwise is overselling. Consentinel
blocks what can be blocked from a WordPress site, records what your visitors chose,
and is explicit about what it cannot reach. Compliance also depends on your own
policies, your server-side tracking, and advice from your counsel. This plugin is
compliance tooling, not legal advice.
### What can it not block?
Three things, stated plainly. Trackers injected by Google Tag Manager at runtime
are invisible to the file and page scanner, though the blocking engine still intercepts
their network requests. Server-side tracking — Meta Conversions API, server-side
GTM, log-based analytics — never touches the browser, so no consent tool sees it.
And anything injected by your CDN after WordPress has finished, such as Cloudflare’s
own scripts, is out of reach of any WordPress plugin.
### Why does “Block until consent” do nothing for my web fonts?
Web fonts and icon kits arrive as a stylesheet, which the browser fetches through
a path JavaScript cannot intercept — no consent tool can stop that in the browser.
Consentinel stops them on the server instead, but only for **Always block**: a stylesheet
cannot be restored after consent, so blocking it “until consent” would leave your
fonts broken permanently. The Tracker scan tab says so where you set the mode.
### Does it slow my site down?
The banner is about 20 KB of vanilla JavaScript and CSS with no jQuery and no external
dependencies. The blocking engine runs before your trackers so it does not wait
on anything. The tracker scan runs weekly in the background, never during a visitor’s
page load.
### What happens to my consent records if I uninstall?
They are kept. The consent log survives uninstall unless you explicitly opt in to
deleting it, under **Consent log Data on uninstall**. Consent records are evidence,
so the default is to preserve them.
### Does it work on multisite?
Yes, per site. Each site in the network has its own settings, scan results and consent
log.
## Reviews
There are no reviews for this plugin.
## Contributors & Developers
“Consentinel Cookie Consent” is open source software. The following people have
contributed to this plugin.
Contributors
* [ sliStudios Web Development ](https://profiles.wordpress.org/slistudios/)
[Translate “Consentinel Cookie Consent” into your language.](https://translate.wordpress.org/projects/wp-plugins/consentinel-cookie-consent)
### Interested in development?
[Browse the code](https://plugins.trac.wordpress.org/browser/consentinel-cookie-consent/),
check out the [SVN repository](https://plugins.svn.wordpress.org/consentinel-cookie-consent/),
or subscribe to the [development log](https://plugins.trac.wordpress.org/log/consentinel-cookie-consent/)
by [RSS](https://plugins.trac.wordpress.org/log/consentinel-cookie-consent/?limit=100&mode=stop_on_copy&format=rss).
## 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”.
## Meta
* Version **0.2.80**
* Last updated **1 day ago**
* Active installations **Fewer than 10**
* WordPress version ** 6.8 or higher **
* Tested up to **7.1**
* PHP version ** 7.4 or higher **
* Tags
* [CCPA](https://wordpress.org/plugins/tags/ccpa/)[consent](https://wordpress.org/plugins/tags/consent/)
[cookies](https://wordpress.org/plugins/tags/cookies/)[GDPR](https://wordpress.org/plugins/tags/gdpr/)
* [Advanced View](https://wordpress.org/plugins/consentinel-cookie-consent/advanced/)
## Ratings
No reviews have been submitted yet.
[Your review](https://wordpress.org/support/plugin/consentinel-cookie-consent/reviews/#new-post)
[See all reviews](https://wordpress.org/support/plugin/consentinel-cookie-consent/reviews/)
## Contributors
* [ sliStudios Web Development ](https://profiles.wordpress.org/slistudios/)
## Support
Got something to say? Need help?
[View support forum](https://wordpress.org/support/plugin/consentinel-cookie-consent/)