If you change the cookie policy version the banner can not be dismissed anymore.
Open incognito and visit the website. Dismiss the banner.
In another browser window, change cookie policy version to a higher value, so for example from 1.0.0 to 1.0.1.
Go back and refresh and the banner reappears.
Dismiss the banner and refresh.
Banner appears again.
Dismiss and browse the site, banner keeps reappearing.
The issue was caused by https://www.drupal.org/project/eu_cookie_compliance/issues/3162563
This made the 0, 1, 2 status codes configurable.
It also made them strings instead of the integers they originally were.
However, not all code in the JS file was updated. By searching for `===` you can find many cases where the status is compared to numerical 0, 1 or 2 and is not using the configured values from the UI which are in fact strings now. This means that even with an original configuration in tact where the codes are still 0 1 and 2 they will no longer match.
Specifically this issue is caused by this code area which is checking numerical instead of strings:
Drupal.eu_cookie_compliance.hasAgreed = function (category) {
var agreed = (_euccCurrentStatus === 1 || _euccCurrentStatus === 2);
if (category !== undefined && agreed) {
agreed = Drupal.eu_cookie_compliance.hasAgreedWithCategory(category);
}
return agreed;
};
The same issue also causes other issues - such as calling hasAgreed is saying false always no matter what was agreed.
There is also an issue with the 3162563 where the checks on status in the opening code to decide if banner should be displayed are also checking numerical values so are additionally broken.
Seems the current 1.19 version shouldn't really be working anywhere I'm unsure if when you dismiss the banner if even other stuff is working properly - it's possible even if you dismiss the banner that checks on hasAgreed will always return false... therefore preventing any code running.
-
-
-
-
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
it-cruYou also run into this issue, when you raise your EU cookie compliance version in eu_cookie_compliance.settings.yml from 1.0.0 to 1.0.1 and users already have the 1.0.0 gdpr cookie set.
Then it only helps if you manually delete the already existing 1.0.0 gdrp cookie in your preferred browser to get cookie banner working normally again. But this isn't what your visitors normally do.
Comment #3
svenryen commentedThanks for the report, I'll have a look tomorrow.
Comment #4
svenryen commentedThere are two bugs at play here, first - as you observed - when the policy version is changed, the value is not set due to the === and the problem you reported.
There's an additional problem with the setting of custom values for the cookie states. When custom values such as A, B and C are entered, the banner still doesn't dismiss when the policy version is changed.
Comment #5
svenryen commentedI think I nailed it down by replacing all the 0, 1 and 2 states with the actual values.
@IT-Cru or @Driskell, can you try out the code from the issue fork in Tugboat and confirm that it resolves the problem? Login and password are both "admin".
Comment #7
svenryen commentedComment #8
it-cru@svenryen: I tested code from MR locally and it resolves my issue, that cookie banner does not switch to agree state after clicking allow cookies with a raised version from 1.0.0 to 1.0.1 (I currently use Opt-In without categories). Redraw of consent is also working fine. This was only a quick check locally, so I think it would be good someone else double check code change from MR.
+1 from me for RTBC
Comment #9
svenryen commentedComment #11
svenryen commentedComment #12
tobiasbFyi: Because the browser caches the JS file with the release version foo.js=1.2.3 therefore the bug is not fixed via patch. You need to wait until a new release is released so that request is then foo.js=1.2.4. We you use JS-Cache from drupal then is should not be a problem.