FAZ Cookie Manager

Yes. Add a Shortcode block to your site-wide footer containing [faz_cookie_settings type="link" text="Cookie preferences"] . The link uses your theme’s styling. Omit type="link" for the existing banner-coloured button. Both support a custom text and additional CSS class .

To replace the floating widget, put the link on every page and disable Banner → Advanced → Show revisit consent widget . Jurisdiction routing may lock that widget on; in that case both controls remain available. The shortcode needs the banner runtime and does not work on pages excluded from the banner. Standard navigation menu labels do not execute shortcodes; custom HTML can use <a href="#faz-consent" data-faz-open-preferences="1" aria-haspopup="dialog">Cookie preferences</a> .

No. A hosting cron that calls WordPress’s wp-cron.php runs the plugin’s scheduled events too. If your host already provides that job, do not add a duplicate. System Status → Cron Jobs includes a cPanel example and explains how to check the next scheduled times.

A saved choice normally keeps the banner closed. Use the revisit control to reopen preferences. With Geo-Targeting on, visitors who need opt-in consent receive an opt-in version of your CCPA banner when no GDPR banner applies; an unknown country receives the protective fallback too. Its look and policy links are preserved.

The WordPress Dashboard and FAZ screens explain fallback coverage and offer Check the banner on your site . This reopens the real banner for your administrator account without clearing consent or changing other visitors’ choices. The global banner switch and configured page/region exclusions still apply. If a cache continues serving a banner-less page from an older version, purge that page cache and any external CDN cache after updating.

Pageview and banner interaction metrics show -- when pageview tracking is disabled. This means unavailable, rather than zero visits. Consent logging is a separate setting and can remain enabled.

No required cloud account or subscription is needed. Core consent features run locally, while some optional refresh/download features can contact documented third-party services such as GitHub, IAB Europe, MaxMind, or AMP infrastructure.

It’s free and open source (GPL-3.0). There are no premium upgrades, no feature gates, and no upsells. The plugin is based on the GPL-licensed CookieYes v3.4.0 codebase, with cloud dependencies removed and all included features running locally.

Yes. The plugin sends all 7 consent signals ( ad_storage , analytics_storage , ad_user_data , ad_personalization , functionality_storage , personalization_storage , security_storage ) and supports Google Additional Consent Mode (GACM) for ad technology providers.

Yes. Known third-party scripts are blocked automatically. To gate one of your own, give it a non-executable type and name the category it belongs to:

<script type="text/plain" data-faz-category="analytics">/* your code */</script>

Both parts are required. The type is what stops the browser from running it before consent; data-faz-category is what the plugin looks for when it runs it afterwards. A script with only the type never runs at all — including after consent — and a script with only the attribute runs immediately, before any consent is given.

The same pair works for iframes, images and stylesheets using data-faz-src or data-faz-href in place of the real attribute.

Once consent is granted the plugin runs the script itself, on that page and on every later page load. You do not need to listen for fazcookie_consent_update to start it; that event is for your own code that has nothing to do with these tags.

Go to FAZ Cookie > Cookies and click Scan Site . The scanner runs in your browser using iframes, crawling your site’s pages to detect all cookies. Choose from quick scan (10 pages), standard (100), deep (1000), or full scan. No external service involved.

Yes. Every consent action (accept, reject, customize) is recorded in a local database table with timestamp, consent ID, categories chosen, a pseudonymised IP (salted one-way hash), and page URL. Export to CSV anytime from the Consent Logs page.

Yes. The Languages page lets you select from 180+ available languages. Each banner you create carries its own translations for every language you enable — the banner text (title, description, button labels) is stored per-language inside the banner row, and the language displayed to the visitor is resolved client-side from navigator.languages . WPML / Polylang URL-based language switching is auto-detected and always cache-safe.

Yes. GTranslate’s paid plans (and similar proxies, mirrors or CDN hosts) serve translated copies of your pages on other hosts — example.de , de.example.com — and forward every request made there, including the consent log and the Do-Not-Sell form, back to your WordPress site. Four things follow, and the plugin handles each one:

• The banner itself. The proxy translates the page, banner included, so on a translated domain the banner shows in that language. The banner markup travels in a <template> element the proxy can translate without breaking its structure. (Up to 1.35.0 it travelled in a script element the proxy also read as HTML, which on the translated domains left the consent bar nested inside the revisit button with no buttons.)
• The consent cookie on a translated domain. A browser cannot share a cookie between different registrable domains, so on example.de the consent is stored for that domain only, even when “Share consent across subdomains” is on for example.com . The visitor makes their choice once per domain. (Earlier versions wrote the cookie for the configured domain, which the browser rejects on another domain, so the banner came back on every page.) A cookie the server itself sets, such as the Do-Not-Sell confirmation, is host-only too.
• Consent records and Do-Not-Sell submissions from those domains. They arrive with the translated domain as their origin and used to be refused as “cross-origin”. The domains GTranslate’s own settings describe (Enterprise plan: custom domains or language sub-domains) are now trusted automatically while GTranslate is active. Any other domain is added under Settings → Trusted Alternate Domains (one per line: a bare domain, or a full URL when the scheme or port matters), or with the faz_trusted_origins filter. System Status lists the effective domains and where each came from.
• “Rate-limited” consent records. Every visitor of the translated domains reaches your server from the proxy’s few addresses, so they share one rate-limit window. The plugin never believes a forwarded address from an unknown sender, because anyone can send one. Ask GTranslate support for the proxy’s address ranges, then declare them and name the header the proxy forwards the visitor’s address in: add_filter( ‘faz_trusted_proxy_cidrs’, function ( $cidrs ) { return array_merge( $cidrs, array( ‘203.0.113.0/24’ ) ); } ); add_filter( ‘faz_proxy_forwarded_header’, function () { return ‘HTTP_X_GT_CLIENTIP’; } );

Replace 203.0.113.0/24 with the ranges you were given; GTranslate publishes its current list at https://gtranslate.net/ips.txt. The filter takes the server variable name of the header: GTranslate forwards the visitor’s address in X-GT-ClientIP , which PHP exposes as HTTP_X_GT_CLIENTIP . See “My site is behind Cloudflare or a reverse proxy” below for how these two filters work.

No — multi-banner routing is per visitor country (e.g. GDPR vs CCPA, EU vs US), not per language. Each banner row carries its OWN multilingual content: title, description and button labels translated for every language you support. The visitor’s country selects the banner; the visitor’s browser language then selects which translated strings to render inside that banner. So an install with one EU-targeted GDPR banner (carrying English + Italian + German + French translations) and one US-targeted CCPA banner (carrying English + Spanish translations) needs only TWO banner rows, not eight. See the “Multi-banner geo-routing vs multilingual content” section in the Description for the full architecture.

Yes. A floating revisit widget appears on every page, letting visitors reopen the preference center and change their choices at any time.

Yes. The banner supports full keyboard navigation (Tab, Enter, Escape), proper ARIA labels, and is responsive down to 375px viewports. Buttons have equal visual prominence to avoid dark patterns.

Yes. See the Cache Plugin Compatibility section below for the verified plugins, emitted cache-control signals, automatic FlyingPress handling and known CDN limitations.

Yes. The consent banner is rendered via JavaScript from a cached template, so it works with all major caching plugins (WP Super Cache, W3 Total Cache, LiteSpeed Cache, etc.).

No. The plugin contains no telemetry, no analytics beacon, and no “phone home”. Dashboard numbers are computed locally from your own wp_faz_pageviews and wp_faz_consent_logs tables. Every outbound request that can happen is documented in the “External services” section and is gated behind an explicit admin action.

The minified files we ship are frontend/js/script.min.js , fronte