Antonio Candela

Hi @chefspuntozero and @nmcjosh,

Thanks for reaching out!

Quick clarification on WordPress 7 support: Complianz is already compatible with WordPress 7. There are still some Compatibility API refinements we’re working on internally, but the plugin itself is fully functional on this version.

@nmcjosh , regarding the specific fatal error you’ve shared, this is actually the first time we’ve received a report of this kind, so it’s not a known issue on our end. To investigate it properly and roll out a fix, could you please open a dedicated support ticket at https://complianz.io/support using the following subject line so we can prioritize and track it correctly:

Subject: Fatal error on plugin activation - WordPress 7.0 compatibility (array_key_exists on null)

In the email, please include:

• The full stack trace you posted here
• Your PHP version
• Whether the free version of Complianz was previously installed on the site
• Any other active plugins that might be relevant

With that information, we’ll be able to look into it directly and ship a fix in the next plugin release.

Thanks a lot for the detailed report, it really helps!

Best regards,
Antonio

Hi @vito33,

Thanks for your patience! We’ve shipped the fix in the latest plugin release, which you can download either here on WordPress.org or directly from the Plugins section of your wp-admin.

Best,
Antonio

Hi @mrmatteastwood ,

Thanks for reaching out!

I had a chance to test this on my side and managed to block it successfully using a slightly different approach. The reason the Script Center URL blocker isn’t catching https://cal.meetergo.com is that the iframe in question bypasses the standard blocking mechanism, so the URL-based block doesn’t apply to it.

The reliable solution in this case is to wrap the iframe in a Consent Area Block, which prevents the iframe from loading entirely until the user gives consent. You can follow the official guide for this here: https://complianz.io/gutenberg-block-consent/.

For the actual HTML structure to use, you can reference the example shared in this WordPress support thread, which covers a very similar case: https://wordpress.org/support/topic/unable-to-block-iframe-2/.

I hope this helps.

Kind regards,
Antonio

Hi @emite,

We have a dedicated guide that covers exactly this issue and walks you through how to resolve it step by step: https://complianz.io/website-scan-stuck-at-75/.

Just follow the steps outlined there and the scan should complete properly afterwards. Let me know if you run into any issues along the way.

Best,
Antonio

Hi Matthew,

At this point, I think we can confidently rule out that the issue is on Complianz’s side, since the banner is working correctly across various devices.

The most likely cause now is something specific to the browser or device you’re using on your end. Privacy-focused browsers like Brave, or any installed ad blockers / privacy extensions, are often configured to block consent banners and similar elements automatically, which would explain exactly the behavior you’re seeing.

If you’d like to confirm this, you could try opening the site in a different browser on your phone (e.g. stock Chrome with no extensions) or temporarily disabling any privacy extensions you might have installed.

If you need further help, feel free to open a new thread.

Best,
Antonio

Hi Mitch,

Thank you for reaching out, and apologies for the translation issues you’re experiencing! We’re already aware of this and a fix will be shipped in the next plugin release.

Thanks a lot for your patience in the meantime.

Best,
Antonio

Hi @atypiclab ,

Thanks for the detailed report, and please accept our apologies for the late reply on this.

I spent some time trying to reproduce the issue on my end using the Age Gate plugin (https://wordpress.org/plugins/age-gate/), but I wasn’t able to replicate the problem you described. On my test setup, the Complianz banner appeared in front of the Age Gate banner without any interaction issues, and I could click the age verification buttons normally.

To dig into this properly, could you kindly help us with a couple of things:

1. A short screen recording (via Loom or any similar platform) showing the issue in action, including your Age Gate plugin settings, that would give us a much clearer picture of how everything is configured on your side.
2. Information about the theme you’re currently using on the affected site, themes can introduce CSS conflicts that affect the pointer-events behavior, so this detail is important.

I also had a look at the test link you shared (https://test-domaine-ampelhus.atypic-lab.fr/), but the site appears to be missing most of its content/styling, which makes it hard to use as a reliable test environment. For comparison, when I tested on a clean Gutenberg-based theme, the issue did not appear at all.

Without being able to reproduce the issue on our side, it’s tricky to give you a concrete fix, but with a Loom and the theme details we should be able to make much faster progress.

Looking forward to your reply.

Best,
Antonio

Hi @mmk175,

Thanks for the detailed report and apologies for the inconvenience!

To get to the bottom of this, could you kindly share the URL of your site so we can check the mobile view directly on our end? Without seeing the live site it’s quite hard to pinpoint what might be going wrong specifically on mobile.

In the meantime, here are a couple of things worth checking on your side:

1. Exclude Complianz from SG Optimizer cache

The most likely culprit when behavior differs between desktop and mobile is caching, especially with SG Optimizer in the mix. Caching plugins sometimes serve different cached versions for mobile/desktop, and if Complianz scripts are being delayed or stripped out on mobile, the banner can fail to render. Please follow this guide to exclude Complianz properly from your caching setup: https://complianz.io/javascript-delay-in-wp-rocket-and-other-caching-and-optimization-plugins/

2. Clarification on “Show everywhere”

Just to clarify a small but important point: the “Show everywhere” setting you mentioned actually refers to the Manage Consent feature, which controls how users can re-access and modify their consent after it’s been given (i.e. the small icon that lets them revisit their preferences). It does not control the visibility of the initial consent banner itself.

That said, our consent banner doesn’t have any setting that restricts it based on mobile vs desktop user agent, so the banner should appear the same way across all devices unless something external (caching, theme conflict, JS error) is interfering.

Looking forward to the site URL so we can investigate further.

Kind regards,
Antonio