Consent widget

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.

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.