disabled scripts not being included after consent

Hi there,
so i take it the gtag.js isn't being included into the page? The purpose of the unverified scripts is to make sure that the script that EUCC has been tasked to run will actually be on the page. So in some way the gtag.js script isn't being included on your page.

i'll install that module and see if i can come with the same issue.

Correct, yes. Even when the user consents, we have no tracking firing...

Hi @newaytech,

I've linked the issue to another that is similar. If you could take a look and test that would be great thanks.

We're experiencing the same issue. No scripts get loaded after consent has been given. Tested MR !161 in 3527482 with no luck.

Attached a patch that seems to fix the issue for us.

Hi folks. I've spent some more time on this today. Discovered as did Alexander - that the patch MR!161 - did not fix up the missing scripts issue. I did try the patch from Alex - which did bring the scripts back - but it felt as though we were undoing what the intention of the "unverifiedScripts" variable truly offered. I dug a little further - and found that the "$all_js = [];" variable was not fully populated with the Google_Tag scripts - so they were quite rightly excluded as not being part of the known libraries. I believe this is due to the order of execution of modules - with the EU compliance module firing before the Google Tag module.

I then moved all of the javascript validation code into hook_page_attachments_alter method - as this fires after the scripts have been initialised by other modules.

Works for me.

I'm not overly familiar with patch creation / merge requests etc. within this module - but happy to supply what I've done by any means if that is helpful - or also would be happy to see someone else create the above solution and post as a patch here.

Hi,

After implementing MR161, did you happent to resave the settings? this would write out a changed eu_cookie_compliance.script.js file with the updated unverified script list in it.

You're correct in saying that Alex's patch undoes the purpose of the unverified script variable, so we need to find a better solution.

My next question is (as i've seen this, but unsure if its a problem), could i get you to put a little debug into public://eu_cookie_compliance/eu_cookie_compliance.script.js to print the category variable (console.log(catagory)). This should be the same as your category machine name i believe. But it obviously has to match options.categoryName in the script otherwise it won't execute.

Thanks for your help in solving this issue.

Hi - shouldn't be using MR161, that just disables the javascript.
I've attached a patch from my branch of 3527482-category-scripts-fix. If you could try that please.

Hi atowl. Tested patch #10 with no luck. I re-installed the patch on a "clean" DB, ran new DB updates and tested again by saving the config form, but still nothing.

I did some debugging and found that unverifiedScripts and scriptList in eu_cookie_compliance.script.js contains the scripts that I want to eventually load on the page. My scripts seem to end up in unverifiedScripts because they aren't found during the $all_js check in the eu_cookie_compliance_page_attachments hook.

How I've added my scripts:
One of my script is being added through hook_page_attachments, and the other is attached to a block with a library in the blocks build method. I should probably mention that my scripts don't have anything to do with gtag.

The settings for the module:
In the modules "Disabled scripts" settings, I have defined these two scripts like this:

modules/custom/my_analytics/js/siteimprove.js||my_analytics/js-siteimprove
modules/custom/my_blocks/js/react-share.js||my_blocks/react-share

So to me it looks like the logic in eu_cookie_compliance_page_attachments needs to be looked at. What I'm also not grasping is why a script would be regarded as "unverified" if the script has been listed in the modules "Disabled scripts" settings?

Morning folks. I can confirm that the patch in #10 works for me - over the top of a 1.26 version.

I don't use categories - so can't help on that front...

Thanks for the patch - do you think this will be going into a release some time soon?

Thanks @newaytech for that

So i've removed the unverified script checks from hook_page_attachments() and left it in the _alter() hook instead, as you pointed out.

Hopefully this resolves it for everyone, if so i'll get a new release out.

Hi atowl,

The latest patch you posted seem to contain changes from other patches that have been posted in this issue. I can't apply it to a clean install of 8.x-1.26.

Hi Alexander,

Apologies for that, lets try that again shall we? I have re-rolled the patch and tested it against the 1.26 release.

Should be all good to go now!

Hi @atowl - yes - the patch at #16 works for me... Thanks for your help in resolution here.

Hi @newaytech!

Glad to hear that's all working, i've merged the changes into the main branch, will release a new version shortly.

Thanks so much for yours and everyones help on this issue.

You're welcome - thanks for the great module too!

Hi there,

I'm facing the same issue after updating the module to the latest version.
Specifically, I can't load the GTM script provided by the module Google Tag (version 1.8) after clicking "consent" on the cookie banner.
It works fine with version 1.25.

The patch provided above doesn't fixthe issue.

The problem is that my JS file (e.g., sites/default/files/google_tag/project_gtm/google_tag.script.js) is continuously added to the $unverified_scripts array.

I suspect this happens because the GTM module is loading my JS script through $attachments['#attached']['html_head'] (see: https://git.drupalcode.org/project/google_tag/-/blob/8.x-1.x/src/Entity/...) rather than in $attachments['#attached']['library'].

I'll try updating the patch code or directly upgrading to GTM version 2.0 to see if that helps and keep you posted.

In the meantime, any support would be appreciated!

Patch attached to fix the issue described above.

Please kindly review and test it.

Hi @guillaumeg,

Sorry to hear it's still not working for you.

I've installed *just* the project_gtm module (added a GTM number), and added your patch, but it never steps into the
if (!empty($library[0]['#attributes']['src']) && $library[0]['#tag'] === 'script') { part of your patch.
Admittely they do add their script into the head, so maybe we do actually need to look at html_head for scripts that might get loaded.

In the mean time, I'm going to mark this issue as being fixed, but could i get you to please start a new issue with the reproduction and the patch (more preferrably an issue fork) so i can start work on your issue.

thanks!

Hi @atowl and thanks for your reply.

The issue occurred with GTM version 8.x‑1.8. I assume you tried it with the latest 2.x version.

I'll stick with my patch until we can safely migrate GTM to version 2.x.

I believe the patch provided could still be useful for other third‑party libraries that use html_head to load their resources.

Hi @guillaumeg,

Yes, all the testing i did for this issue i used drupal/google_tag^2.0.8 (to be specific).

So you are using the 1.8 version? I can try again with that.

Same happened with our project. We are using https://www.drupal.org/project/google_analytics/releases/4.0.3 →

We are using categories and here are the relevant disabled scripts setting values:

analytics:https://www.googletagmanager.com/gtag/js
analytics:modules/contrib/google_analytics/js/google_analytics.js

Before 1.27 it used to work, with it scripts aren't loading after agreeing. The patch has fixed the issue, thank you @guillaumeg

Hi @atowl,

Yes I am using GTM 1.8 as of now.

@elaman glad to read that my patch helped!