Richard

Hi @thebigbang,

I would very much recommend using our plugin to add the Cookiebot banner for the best results, not the Header and Footer plugin.
I suspect you’ve done both, explaining the repetition.

Regarding the warning, this is not something you can fix yourself. But it’s also not really a problem. Facebook will more than likely make the necessary changes to their script when the future release of Chrome goes live.

Hi @jatinder1987,

This happens if you implement the script twice, for example using both Google Tag Manager and the WordPress addon.
I only see the GTM implementation on your domain though.

Are you still affected by this issue?

Hi @guillaumepro,

Could you provide a link to the affected page? I’d like to to investigate this matter further.

If you’re uncomfortable sharing this information on the forums, please write to [email protected] and refer to case number: 39125

Hi @mikegracia,

To make the links appear and the shortcodes work, the Cookiebot script needs to be present on the page. If it isn’t consent settings can’t be retrieved and/or updated/revoked

Hi @dan14

Unfortunately this isn’t something our script has any influence on, it doesn’t compress (or decompress) files. It works more like an on/off switch.

Cookie setting resources are disabled before they load and are “switched on” when the user consents to the cookies it sets.

It appears I was mistaken, my apologies.
The file has now been compressed.

• This reply was modified 4 years, 11 months ago by Richard.
• This reply was modified 4 years, 11 months ago by Richard.

Hi @lorenzogiuntini1983,

This is part of the auto blocking feature. Scripts that set trackers are disabled, by changing the type to “text/plain”.
If some of these scripts are necessary for the correct functioning of your page, you may consider assigning the “necessary” category to the cookie(s) set by these scripts in the Manager.

Another option, is to assign the data-cookieconsent=”ignore” to scripts you don’t want blocked. Be careful though! Any script with this attribute will be able to set cookies without consent. Furthermore, if the script has references to other scripts that aren’t ignored, reference errors may occur.

Hi @khuffu,

Jusging from your description, I suspect you’ve added but the Cookiebot (banner) and the CookieDeclaration scripts in the header.

The CookieDeclaration script should only be used on your cookie policy pages. The table will then be rendered in the spot where you insert the script in the body of the page.

Hi @ilpixelmatto,

I’ve heard of this issue before, “smush” is the cause of it. This isn’t because it gets blocked, but because it waits for an event before it runs. By the time the Cookiebot script allows Smush to load, the event has already occurred, trapping the script in an indefinite waiting state.
The reason it works when you submit a full opt-in is because that disables the auto blocking function (since nothing needs to be blocked anymore).

You can do a couple of things to prevent this:

1. Use manual mark up
2. Force the script to be ignored by the auto blocking feature, by assigning data-cookieconsent=”ignore” to the script tag of the Smush script
3. Remove the Smush script

Hi Jose,

That’s difficult to say, since I can only see the result of how you’ve built your site in WordPress, not how this is done.

The source code mentions something called “Fusion” which adds the footer. I’m not familiar with this plugin, but perhaps you can remove/replace the document.write method.
Alternatively, you’d have to reach out to the author of the plugin and request they replace their method to output the date.
It’s very minor and easy change, so I can’t imagine they would be unwilling to accommodate you.

Hi @crkjl,

The white area is caused by the use of the document.write method. Due to how the auto blocker works, the output of that command is delayed, resulting in the output being added after the content of the page.

Replacing document.write with a different method, like innerHTML should work.

Hi @saggi87

It seems like Cookiebot isn’t the first script on the page to load. This means that the any script that loads before it can set cookies without consent.

I would recommend using our WordPress plugin to implement Cookiebot, this ensures that it’s the very first script on the page to load.

Hi @zjwessa,

I apologize for the delayed response.

We generally recommend using the Plugin for WordPress users. Not only is this an easier method than manual implementation, but it also guarantees that the script is put in the right place, so that no cookies can slip though.

I recommend removing all previous Cookiebot implementations (so you have a clean slate), get the latest version of the Cookiebot WordPress plugin, and input your CBID.
The standard settings should work for most of our users.

Hi @zarachrome,

Have you upgraded the Cookiebot plugin to the latest version? I know version 3.4 and above completely disable the Cookiebot script in the back end.

• This reply was modified 5 years, 1 month ago by Richard.

Hi Jay,

If you’re using WordPress, the only sure way to implement the script in such a way that you can be sure that the Cookiebot script is the first to load, is to use our Plugin.

Any other way can’t guarantee that the script loads first, which means that some scripts may execute first and set cookies. Not executing the Cookiebot script is also know to cause errors in event handling, making some features break.

Judging from your description, changing the implementation method should fix the issue you describe.

Hi @hole19,

The Cookiebot script fails because the variable “i” is defined as a global constant (with the value “false”). This means that “i” has a fixed value, and that any attempts to change or redefine the variable will result in an error.
This becomes a problem when we try to define “i” in a “for” loop. For example: for(i=0;i<something;+ii)

To fix the error, “i” needs to either not be on a global scope, or to not be defined as a constant.

• This reply was modified 5 years, 2 months ago by Richard.