Title: Consent widget
Last modified: August 22, 2026

---

# Consent widget

 *  [palovk](https://wordpress.org/support/users/palovk/)
 * (@palovk)
 * [2 weeks, 2 days ago](https://wordpress.org/support/topic/consent-widget/)
 * The revisit consent widget is still visible. It cannot be turned off.
 * Version **1.27.0**

Viewing 4 replies - 1 through 4 (of 4 total)

 *  Plugin Author [fabiodalez](https://wordpress.org/support/users/fabiodalez/)
 * (@fabiodalez)
 * [2 weeks ago](https://wordpress.org/support/topic/consent-widget/#post-19001674)
 * You are right, and it is not something you are doing wrong. The switch genuinely
   cannot turn the widget off at the moment, and until now nothing told you why.
 * When a visitor resolves to a jurisdiction with a rule set, the runtime applies
   that rule set to the banner before it renders. 47 of the 48 rule sets shipped
   with the plugin carry a requirement for a standing way to reopen and withdraw
   consent, so the widget is forced back on for those visitors regardless of your
   setting. The reasoning behind it is that under GDPR and the laws modelled on 
   it, withdrawing consent has to be as easy as giving it — if the only way to say
   yes is a banner that then disappears forever, there is no equally easy way to
   change your mind later.
 * So the widget staying put is deliberate. What was not deliberate is that the 
   plugin let you switch it off, save, reload, see no change and find no explanation
   anywhere. That is my fault and it is fixed in the next release: the control is
   disabled with the reason next to it whenever a rule set is enforcing it, rather
   than quietly doing nothing.
 * What you can still change is everything about how it looks. Position, background
   colour, icon colour and the icon itself are all yours, and they are right below
   that switch. If the widget is too prominent for your design, that is where to
   work — a small, quiet icon in a corner satisfies the requirement perfectly well.
   Tell me what you are after and I can suggest settings.
 * If your site serves no visitors in the EU, the UK, Switzerland or any of the 
   other jurisdictions with a rule set, the runtime can be turned off entirely with
   the faz_geo_ruleset_runtime filter, and then the switch behaves as you expect.
   I would only do that if that is genuinely your situation, because it also switches
   off the rest of the per-jurisdiction handling.
 *  Thread Starter [palovk](https://wordpress.org/support/users/palovk/)
 * (@palovk)
 * [2 weeks ago](https://wordpress.org/support/topic/consent-widget/#post-19001834)
 * Thanks for the explanation. I had it solved via [faz_cookie_settings text=”xy”]
   in the footer as a button. In your opinion, is this not GDPR compliant?
 *  Plugin Author [fabiodalez](https://wordpress.org/support/users/fabiodalez/)
 * (@fabiodalez)
 * [1 week, 5 days ago](https://wordpress.org/support/topic/consent-widget/#post-19003528)
 * That works, and yes it is compliant — with three things worth checking, because
   two of them can make it look compliant while it quietly is not.
 * The legal requirement is Article 7(3): withdrawing consent has to be as easy 
   as giving it. It does not prescribe a floating widget. A persistent link or button
   is the most common implementation in the field and is accepted by the French,
   Italian and UK authorities alike. So your footer button is not a workaround, 
   it is the ordinary way to do this.
 * And the shortcode is the right one. I checked what it actually renders rather
   than assuming: it emits a real button carrying aria-haspopup=”dialog”, and the
   click handler opens the exact same preference centre the banner’s own Customize
   button opens. Same dialog, same withdrawal path, same categories. It is not a
   shortcut to a read-only screen.
 * The three checks. First, the footer has to appear on every page — if a landing
   page template, a checkout, or a page builder layout drops it, then on those pages
   there is no way to withdraw, and that is precisely where the requirement fails.
   Second, give it a label that says what it does; you wrote text=”xy”, which I 
   assume is a placeholder, but if that is the real label then the control exists
   without being findable, and a control nobody can identify is not an accessible
   one. “Cookie settings” is fine. Third, and this is the one that catches people:
   if the page is listed under Settings, Banner Control, Excluded pages, the banner
   runtime is not loaded there at all — so the button renders and does nothing. 
   It looks correct and is inert. That is the worst failure mode of the three because
   nothing on screen tells you.
 * Now the part where you have found a genuine gap in my plugin rather than in your
   setup.
 * The runtime forces the revisit widget on unconditionally. It never asks whether
   an equivalent withdrawal control already exists — it checks for one specific 
   implementation instead of checking for the property that implementation is meant
   to guarantee. So you did the right thing, built the footer button, and the plugin
   still imposes a second control for the same function with no way to turn either
   one off. That is my bug, not your misconfiguration.
 * Detecting it automatically is genuinely hard: whether a shortcode is rendered
   on every page of a site is not something the plugin can determine from the inside.
   But the decision can be handed back to the person who can verify it. I am adding
   an explicit acknowledgement next to that toggle — along the lines of “I provide
   another always-available control for withdrawing consent” — which unlocks it,
   with those three conditions written next to the checkbox. Ticking it is an informed
   choice; being blocked with no explanation, which is what you ran into, is not.
 * Until that ships, the widget stays forced. If it is too prominent for your design
   in the meantime, its position, background colour, icon colour and the icon itself
   are all configurable right below that toggle, and a small quiet icon in a corner
   satisfies the requirement perfectly well.
 *  Thread Starter [palovk](https://wordpress.org/support/users/palovk/)
 * (@palovk)
 * [3 days, 18 hours ago](https://wordpress.org/support/topic/consent-widget/#post-19011495)
 * Thank you for the detailed explanation.

Viewing 4 replies - 1 through 4 (of 4 total)

You must be [logged in](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fwordpress.org%2Fsupport%2Ftopic%2Fconsent-widget%2F%3Foutput_format%3Dmd&locale=en_US)
to reply to this topic.

 * ![](https://ps.w.org/faz-cookie-manager/assets/icon-256x256.jpg?rev=3519691)
 * [FAZ Cookie Manager](https://wordpress.org/plugins/faz-cookie-manager/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/faz-cookie-manager/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/faz-cookie-manager/)
 * [Active Topics](https://wordpress.org/support/plugin/faz-cookie-manager/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/faz-cookie-manager/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/faz-cookie-manager/reviews/)

 * 4 replies
 * 2 participants
 * Last reply from: [palovk](https://wordpress.org/support/users/palovk/)
 * Last activity: [3 days, 18 hours ago](https://wordpress.org/support/topic/consent-widget/#post-19011495)
 * Status: not resolved