Antonio Candela

Hello @asafm7 ,

Thank you for reaching out.

In cases like this where the category attribute approach isn’t working as expected, it’s better to work the other way around by embedding the script normally and then blocking it through Complianz.
This logic can be applied to almost anything in our plugin.

Here’s what you need to do:
Step 1: Replace your current code in the Divi header with:

<script type="text/javascript" src="https://t.contentsquare.net/uxa/9f71c33263b3a.js"></script>

Currently it will load before consent, so we need to block it.

Step 2: Block the script in Complianz

1. Go to Integrations > Script Center > Block a script, iframe or plugin
2. Add a new block (or edit an existing one if you already have blocks in place)
3. Under “URLs that should be blocked before consent”, add: t.contentsquare.net
4. Set the category to Marketing
5. Save the settings

Step 3: Make sure to clear any caching plugin cache you have active on your site.

Once done, you should be all set. The block configuration should look like the this: https://prnt.sc/goUQ1u_GNASY.

I have tested this in my environment and it works correctly, the script is blocked until consent is given for the Marketing category.

Let me know if this helped.

Best regards,
Antonio

Hello @wpreceiver ,

Thank you for reaching out.
To answer your question: no, these cookies are not the same.

• cmplz_policy_id: This indicates the version ID of the Cookie Policy currently generated by the Wizard. It ensures that if you update your policy, the banner reappears for users to re-consent.
• cmplz_id: This cookie is used to assign a unique ID to a specific user’s consent. This is only available if you enable the Records of Consent feature, which is part of the Premium plugin.

You can find this setting under Wizard > Security & Consent > Do you want to enable Records of Consent?
So, in summary, the Premium version is indeed required to access the cmplz_id.

I hope this clarifies things. Have a great day!

Best regards,
Antonio

Hello @marzamele ,

Thank you for reaching out.

If Cloudflare Turnstile is not appearing in your Cookie Policy list yet, you likely need to synchronize your cookie data with CookieDatabase.

Please try the following steps:

1. Go to Wizard > Consent > Cookiedatabase.org and click Sync.
2. If the service still does not appear, try running a new scan first under Wizard > Consent > Website Scan.
3. Once the scan is finished, perform the Sync again (refresh the page if needed).

After doing this, the service and its cookies should appear correctly in your policy. If they still do not show up, please let me know so we can check further.

Best regards,
Antonio

Hello @annetteschwindt,

Thank you for reaching out.

The issue with the ‘giant cross’ (oversized close icon) will be addressed in the next version; it is a simple CSS value adjustment.

The icon appears this way because the banner is momentarily loading without styles (Flash of Unstyled Content). This often happens due to caching or optimization settings. Please follow this guide to exclude the necessary parameters from your caching plugin: https://complianz.io/javascript-delay-in-wp-rocket-and-other-caching-and-optimization-plugins/

That said, we are actively looking into this broader issue regarding the unstyled banner loading, as we have received other reports about it.

I hope this helps. Please let us know if the caching exclusion resolves it.

Best regards,
Antonio

Hello @rayeason,

Yes, you need to have the toggle set to ON.

In an opt-out configuration, the blocking of scripts (and the consequent display of the placeholder) only happens if a user explicitly opts out using the preferences or the Cookie Policy page.

If you saw the placeholder with the description before any interaction, it is because the site was using an opt-in configuration at that moment.

Best,
Antonio

Hello @testcs1041 ,

Thank you for reaching out.

If the cookie banner appears on all other pages, then the plugin is working correctly. On the Cookie Policy page, the behavior is intentionally different: the banner does not appear as a popup. Instead, the consent settings are embedded directly inside the Cookie Policy content.

In this embedded section (usually point 7.1), visitors can view and change their preferences directly within the text. You can verify this behavior on your own Cookie Policy page or see an example on our site here: https://complianz.io/legal/cookie-policy/#:~:text=7.1%20Manage%20your%20consent%20settings.

I hope this clarifies the matter.

Best regards,
Antonio

Hello @kingbrown75 ,

Apologies for the delay in my response.

Loading Google Tag Manager and/or Google Analytics is included in the free version. You can essentially do everything in the free setup except enabling Google Consent Mode v2. As mentioned before, Consent Mode v2 requires an upgrade; and enabling it via Site Kit will not make it work.

Regarding the situation where Site Kit is present and GTM is loaded by Complianz (you can usually tell from the HTML comments in the page source): this happens because the “Site Kit” integration in Complianz → Integrations → Plugins is set to OFF. When that integration is OFF, the fields in the Statistics configuration are not hidden (they are only hidden to prevent a double implementation when the integration is ON).

So, with the configuration you described: if the integration is OFF and Site Kit is not placing the code (e.g., Tag Manager/Analytics toggles are disabled in Site Kit), then GTM will be managed by Complianz. The same logic applies to GA Pro: if the GA Pro integration is set to OFF, the fields in Statistics configuration remain visible.

Last but not least: the “CMP may be blocking tags” warning in Tag Assistant can be expected whenever a CMP is used. Tag Assistant detects that a consent solution is present and warns that tags may be blocked until consent is given, this is not specific to Complianz and generally appears for most CMPs.

Best regards,
Antonio