FAZ Cookie Manager

Changelog

The full changelog (every release back to 1.0.0) lives at:
https://github.com/fabiodalez-dev/FAZ-Cookie-Manager/blob/main/CHANGELOG.md
and on the GitHub Releases page:
https://github.com/fabiodalez-dev/FAZ-Cookie-Manager/releases

1.34.3

• Added: A new switch under Settings → Script Blocking, “Allow anti-spam services before consent”, decides whether Google reCAPTCHA, hCaptcha and Cloudflare Turnstile load before consent (#343). It is on by default, so nothing changes for existing sites. Switched off, those services are held under the Functional category until the visitor accepts it, with no custom rule needed, and the CAPTCHA entries the plugin adds to Script Blocking Exceptions by default are ignored; exceptions written by the administrator still apply. Forms protected by a CAPTCHA cannot be submitted before consent while it is off.
• Added: Slovak banner, preference centre, cookie category and cookie descriptions, contributed by Tomáš Jenej (#332). Cookie durations in Slovak now use the correct plural forms (2 dni, 5 rokov, 1,5 roka).
• Fixed: The CAPTCHA endpoints were added to the script-blocking whitelist in code, ahead of every rule, so neither removing them from the exceptions nor a custom blocking rule could hold reCAPTCHA until consent (#343).

1.34.2

• Added: Your consent ID is now shown in the cookie preferences, the data request form has an optional Consent ID field filled in automatically, and administrators can open the matching consent history from the request. The request also records whether the ID matches the consent cookie of the browser that sent it, and warns the administrator when it does not (#327). WordPress export and erasure tools include that history once the administrator confirms the ID belongs to the requester (filter: faz_consent_log_erasure_retain).
• Added: The suggested privacy policy text is now built from the features actually enabled on the site, including consent IDs, hashed IP and browser data, retention periods, geolocation, the optional ipinfo.io lookup and privacy requests.
• Added: Each consent record now also stores its time in UTC. Existing records are converted in the background after the update, using the site’s current time zone.
• Fixed: On WordPress multisite, a cookie choice made on one site could be applied on another site of the same network, including subdirectory networks and shared cookie domains. Each site now keeps its own choice, also in the Do Not Sell form; visitors of multisite networks are asked once more after updating.
• Fixed: The geo rule sets declared IAB GPP support that the plugin does not provide. The declaration is removed, and custom rule sets that still contain it keep working; a GPP string supplied by another consent platform is still recorded in the consent log, also when the visitor leaves the page right after choosing, and only when it has the shape of a GPP string.
• Fixed: Embedded documents held back by server-side blocking could be released by copied or forged markup. They are now restored only when they belong to the page that was served, and a forged hold marker in the page no longer keeps a provider address loading in the browser.
• Fixed: The “How to Manage Cookies” section of the cookie policy always pointed to the floating cookie icon; it now describes the withdrawal route configured on the site. Where the controller’s name is still missing, the opening sentence of a generated policy now names “the operator of this website”, in the policy’s language, so it keeps stating the law the policy follows; a sentence that only gives a missing contact is left out, so visitors see no asterisks and no sentence ending on a colon over an empty list. The CCPA and LGPD texts present the retention figure as a fallback instead of the retention of all personal data, and the transfer note in the preferences follows the rules applied to the visitor.
• Fixed: A few spellings still let a provider load before consent: a address set by a script, a CSS @import written with a comment, character references without a semicolon, named references and line breaks inside embedded documents, and an inline data script followed by code after a line break. They are now held back, and a “lite” video embed added by a script keeps its preview instead of being replaced by the placeholder.
• Fixed: While the consent runtime was still loading, a script that inserted an element next to one that was being held (insertBefore, replaceChild, before, replaceWith) lost the new element, and with replaceChild and replaceWith both.
• Fixed: An acceptance given on an AMP page by a visitor in an opt-in region, over the kept US banner, was stored for a year; it now gets the opt-in lifetime of at most six months.
• Fixed: Before the visitor had made a choice, the TCF API reported legitimate interest as established for every vendor while the preference centre showed it switched off. Both now say off until a choice.
• Fixed: An expired form and an invalid consent ID on the data request form now trigger faz_dsar_rejected like every other refusal, and the consent ID error says the field can be left empty. After an erasure, the administrator is no longer told that an unverified consent ID can still be verified.
• Fixed: On AMP pages, a site whose geo rules required opt-in consent but which had no GDPR-family banner (for example one set up as “US only” by the wizard) lost both the consent prompt and the blocking, so analytics, ads and pixels on AMP ran without consent and were cached that way by the AMP caches. The prompt and the blocking now stay, as they already did on regular pages.
• Fixed: A consent given under one law or banner (for example the US notice) was honoured by the server and by Google Consent Mode on a page served under another (for example the GDPR banner after travelling or a VPN), until the banner script noticed and withdrew it. Every layer now rejects a consent cookie from a different scope before anything runs. Sites without geographic routing ask again only when the law changes, not when a banner is renamed or the WordPress salts are rotated, and on cached pages Google Consent Mode waits for the visitor’s region and then restores the stored choice.
• Fixed: Vendors that queued a request on the TCF API before the consent framework finished loading never got an answer: the queue was discarded. Queued commands are now replayed.
• Fixed: The consent log stored the TC string of the previous decision, so a Reject row carried the Accept All string. Each row now records the string of its own decision.
• Added: Right to Object in the IAB TCF section of the preference centre, per purpose and per vendor. Legitimate-interest signals are no longer sent for vendors the visitor switched off or after Reject All, the switches are never shown pre-ticked, and vendor consent is only signalled for vendors that were actually shown to the visitor. Vendors the Global Vendor List marks as deleted are no longer listed or signalled, the list is downloaded as soon as TCF is switched on, and the TCF dates follow the IAB day-level rule.
• Fixed: A withdrawal made within ten seconds of an acceptance, from the same browser, was dropped by the flood limit, so the log kept saying “accepted”. A correction by the same visitor now goes through; new visitors from one address are still limited.
• Fixed: With Advanced Consent Mode, a custom blocking rule that happened to match the inline Consent Mode default could neutralise it while the Google tags still ran. The default is now protected from the blocker.
• Fixed: Server-side blocking missed video and audio sources and posters, legacy object and embed players, inline style attributes, compact CSS imports and stylesheets inside noscript, all of which load before any script runs. They are now held back until consent like images and frames, and the consent runtime gates the same elements when scripts create them.
• Fixed: A theme or edge service that supplies the visitor’s country through the faz_visitor_country filter was not counted as a country source when deciding whether a page may be cached, so a page rendered for one jurisdiction could be served from cache to another. Tor exits flagged by Cloudflare now go to the most protective rules, a country looked up for an explicit IP address no longer comes from the current visitor’s Cloudflare or mod_geoip header, and geolocation caches no longer store a plain hash of the visitor’s IP.
• Fixed: The data request form refused every submission when its page was served from a full-page cache for longer than the security token lives, and the Do Not Sell form could cache one visitor’s state for everyone. Both pages are now kept out of page caches, the Do Not Sell form recovers an expired token on its own, and every refusal names the email fallback.
• Fixed: The consent log now records the jurisdiction that was actually enforced, includes the TC string, GPP string, GPC and DNT signals, country and ruleset in the CSV export, adds the time in UTC, and single Do Not Sell records can be fetched by id.
• Fixed: Generated cookie policies could be published with no controller name or contact for GDPR, CCPA and LGPD; publishing now requires them, while a page already live keeps showing for visitors. International transfers are described under the document’s own law (LGPD, POPIA or neutral) instead of always citing the GDPR, the legacy cookie table shows transfer disclosures too, Dutch and Croatian policies are fully translated, and the consent-record period comes from the consent-log setting.
• Fixed: The WP Consent API was told the banner’s law instead of the regime actually applied; the IAB labels are now translatable; GPC no longer rewrites the consent cookie on every page view; explicit blocking rules are kept on the client under the payment-gateway exemption; restored embeds keep the site’s sandbox and referrer settings; uninstall with data removal also removes the plugin’s user meta; and wp faz status reports per-service consent correctly.
• Fixed: The inline bootstrap that protects the page while the consent runtime downloads now stands down when an optimiser runs it after the runtime, and hands over to a runtime that arrives late, instead of staying in its fallback mode for the whole visit.
• Fixed: Query Monitor’s admin bar stopped working on any page that loaded a tracker, because its inline data block names the page’s scripts and FAZ read a tracker signature inside it (#322). An inline script that only assigns JSON data is no longer searched for tracker signatures, in both places FAZ judges inline scripts; the script is still judged by its own id, and any call or statement next to the data is checked as before.
• Fixed: The “Site Kit by Google” entry of the provider list and its blocking template matched every file of the Site Kit plugin, so its admin bar, dashboard scripts and consent-mode bridge were blocked until analytics was accepted, for the administrator too (#322). The entry now matches only the gtag.js tag Site Kit prints for Google Analytics.
• Fixed: With LiteSpeed, or any script that moves elements one by one, pages could freeze and run the browser out of memory: “Remove Query Strings” served the previous consent runtime under the new page, and the inline protection never let such a loop advance. Held elements now move at once, the hold has a hard limit, an older runtime is handed the page, and FAZ asset URLs keep their version under “Remove Query Strings”.
• Fixed: A page rendered for a returning visitor whose consent, Global Privacy Control signal or Do Not Sell choice changed the server-side blocking could be cached and served to everyone. Such responses now stay out of shared caches (filter: faz_veto_cache_for_visitor_state). Under CCPA, sale and sharing scripts are held in the cached page and released in the browser only when the visitor has not opted out (filter: faz_ccpa_park_sell_share_by_default).
• Fixed: Sites that cannot resolve a country no longer disable the page cache because TCF, country banners or AMP are configured. Cache bypasses now also reach CDN caches, Vary: Accept-Language is gone, a server-side A/B test no longer freezes one variant in cache, and the Pinterest app is no longer treated as a crawler.
• Fixed: FlyingPress delayed the banner until the first click when FAZ was served from a CDN or the page used reCAPTCHA. FAZ is now excluded from “Delay third-party scripts” and “Remove unused CSS”, and rewritten FAZ tags are restored before caching. Page caches are also purged after scheduled scans, vendor-list updates and Cookie Policy saves, with new support for Nginx Helper, Proxy Cache Purge, WP-Optimize and Super Page Cache.
• Fixed: With more than about 420 IAB vendors, Accept All granted no vendor consent. The vendor record is now compact, the banner asks again when vendors are added, and the vendor list downloads in the background.
• Fixed: An inline script containing video, image or source markup could be broken by the server-side blocker, and unusual comment or SVG markup could hide a tracker from it. When the blocker cannot finish a page, it now blocks instead of letting the page through.
• Fixed: Tooltips and popovers that keep HTML in an attribute (data-html, title) were broken by the server-side blocker when that HTML held an image or an embedded frame. Tags written inside an attribute value are now left alone; the images and frames on the page are blocked as before.
• Fixed: Consent records and data requests from pages cached for days were refused; both now fetch a fresh token before sending.
• Fixed: The browser-language switch gave up after 500 ms, so visitors on slower hosts kept the default-language banner.
• Fixed: System Status “Copy” included help text and the full provider catalogue, which forums rejected as spam; it now copies the readings only.
• Fixed: The Czech cookie policy said consent was asked before strictly necessary cookies were set; it now says before optional ones, in the templates and in the translated policy strings (thanks to vvvamik, #331).
• Fixed: Generated cookie policies no longer leave the “Cookies used” heading empty when no cookie is declared: it now says so, and that note and the “None declared.” note under third-party services are written in the policy’s language, Brazilian Portuguese, Spanish and Bulgarian included, instead of English. The Brazilian LGPD policy now gives the Art. 19 deadlines for confirmation and access (immediately in simplified form, or a full statement within 15 days) instead of promising a “reasonable period”.

1.34.1

• Fixed: A data request submitted through [faz_dsar_form] could not be acted on from the admin. The link in the notification email opened a record that showed a title and nothing else, so honouring the request meant retyping the address into Tools → Erase Personal Data by hand. The record now shows what was submitted and creates the matching WordPress privacy request — erasure for Art. 17, export for Art. 15 and Art. 20 — with WordPress’s own confirmation email verifying the address first. Requests are also listed under the plugin menu, with requester, right invoked and status.
• Fixed: The data request form accepted an unbounded number of submissions. The 60-second lock per address only spaced them out, so one a minute with a fresh email each time went on indefinitely. There are now cumulative 24-hour ceilings, per address and site-wide, all filterable; the window closes 24 hours after the first submission rather than rolling forward while a flood lasts. The site-wide ceiling bounds the emails, not the right to submit: past it a request is still recorded and the per-request emails stop, so a flood cannot switch off anyone’s right to make a request. It cannot hide one either: the admin gets an hourly summary instead, and the number of requests awaiting action is shown on the plugin’s menu, which does not depend on email at all.
• Fixed: The per-connection limit on the data request form needed an address that identifies one visitor, and on a site behind a CDN or a reverse proxy it did not have one: every visitor arrived as the proxy’s address, so five submissions closed the form for everybody else for 24 hours. The visitor’s address is now resolved on its own behind Cloudflare; another CDN is declared with the faz_trusted_proxy_cidrs filter (plus faz_proxy_forwarded_header if it writes a header of its own), and a reverse proxy on the same host with faz_loopback_proxy_header, which is unset by default because a header the local proxy does not write arrives from the visitor untouched and guessing it would let a visitor choose their own limit. Where no per-visitor address can be found the per-connection limit is skipped instead of being applied to the whole site — the site-wide limits still bound a flood. A forwarded header is still ignored when it cannot be vouched for, so nobody can choose their own limit by sending one. The admin is told when the limit refuses a request, and when it is not in force, with the filter names to set.
• Added: faz_dsar_pre_submit, so a form-protection plugin (ALTCHA/OpenPorte, Turnstile, hCaptcha, Akismet) can gate the data request form. Those plugins protect the forms they know about and could not see this one; a filter returning a WP_Error now refuses the submission and shows its own message to the visitor.
• Fixed: Honouring an erasure from the new button deleted the stored request along with the personal data in it, so the record that showed a request had been received and answered went too. The request is now redacted instead: the name, the address and the message are removed, and what stays is the right that was invoked and the date — enough to demonstrate compliance, identifying nobody. No hash of the address is kept. One thing worth knowing: an erasure matches the email address rather than a single request, so every stored request from that address is redacted together, including one that is still waiting for an answer; the summary WordPress shows you now says how many of those there were.

• Added: Anti-bot protection on the data request form. The honeypot field is no longer at a fixed name a script can skip, and the form carries a signed timestamp so a submission that arrives in under three seconds, or from a page left open for a day, is refused. An optional proof-of-work check (off by default, no third-party service, no API key, no cookie, no puzzle to solve) can be switched on with one line. Every check lets the request through if it cannot run — with JavaScript off the form still works — because this form exercises a legal right and a protection that fails must not become a refusal. Put plainly: the proof of work and the dwell stamp only charge clients that run the form’s JavaScript and never reject a client that omits them (fail-open by design), and the cumulative ceilings are the control that actually stops a spam chain.

• Fixed: The withdrawal fallback widget reappears when theme attributes or CSS transitions and animations hide the footer link after consent.

• Fixed: PHP GeoIP status requires a successful lookup, checks MMDB after extension failures, and explains how to repair a failing source.
• Fixed: The consent banner disappeared on sites with a full-page cache and came back when the cache was turned off. Hiding the banner from search-engine crawlers is on by default, which makes the page different for a crawler than for a person — and a cache does not distinguish the two, so the first crawler to visit a page left a copy with no banner that was then served to everyone, with tracking scripts unblocked. Link previews from WhatsApp, Telegram, Discord, X and Pinterest count as crawlers too, so simply sharing a page could do it. The banner is now hidden from a crawler only on a response that is also kept out of every cache, and if that is not possible the banner is shown instead. AMP pages are covered as well, and updating the plugin clears the caches, so an affected site is fixed as soon as it updates.
• Fixed: The generated configuration and main banner JavaScript load with ordered defer, removing their render-blocking requests. A small inline bootstrap protects dynamic scripts, images, frames, embeds, stylesheets and network calls until the full consent runtime is ready, and the deferred loading is only used when that protection is really in place on the page being served.
• Fixed: Resources that a script or a page builder inserts as HTML, rather than by setting an attribute, are now protected during that window too. The previous version of this change left them unprotected and, worse, left them unexamined afterwards, so a tracker inserted that way stayed live for the rest of the visit with no placeholder and no way for the visitor to decide about it.
• Fixed: A responsive image list (srcset) is now checked candidate by candidate instead of being judged on its first entry, so a list that starts with one of your own images can no longer smuggle a tracker in behind it.
• Fixed: Anything held back is now stored so it can be restored: before, a resource that was only meant to be delayed could end up switched off for the rest of the visit even after the visitor accepted everything.
• Fixed: Google Consent Mode defaults and the TCF command stub remain available before page scripts, and a failed configuration download keeps pending resources blocked. If the consent runtime cannot load at all, same-origin requests are released so the site keeps working, third-party resources stay blocked for the rest of the visit, and the browser console explains what happened and where to look.
• Fixed: A reopen link in the footer could be accepted as valid on the strength of text no visitor can click, so the plugin hid its own revisit widget and the site was left with no usable way to withdraw consent. The check removes script, style, title and textarea regions before looking for the link, but it ended those regions at the first tag whose name merely started the same way — </titlex> closed <title> — and treated the text after it as real markup. Those regions now end exactly where HTML says they do.
• Fixed: A tracker named inside an image-set() or src() value, after one of your own images, was seen by the server-side protection but not by the consent runtime that takes over from it. On a high-resolution display the request went out before the visitor had chosen anything.
• Fixed: A tracker address written with backslashes, or with a scheme and no slashes (https:tracker.example/p.png), inside an embedded document was read as a tracker by the server and as nothing by the runtime. Browsers resolve every one of those spellings to the same host, so the request went out.
• Fixed: A stylesheet address carrying credentials before the host (url(https://user@tracker.example/f.woff2)) was not recognised as belonging to a known provider, so the resource was not held back. Firefox does fetch such addresses.
• Fixed: An embedded document written directly in a post could be damaged rather than delayed. The pass that protects scripts wrote its own attribute inside the embedded markup and cut the document short at the first quotation mark, so the embed was destroyed instead of being restored after consent. The embed is now set aside untouched and comes back exactly as it was written.
• Fixed: With the new deferred loading, the IAB TCF framework could report its own interface as not displayed while the consent banner was on screen, so a vendor asking through the TCF API was told the notice had never been shown. The runtime already recorded that the banner had appeared; the framework now reads that record instead of relying only on an event it could arrive too late to hear.

Older versions

Older releases (1.34.0 and earlier) are listed in the full changelog on GitHub, linked at the top of this section.