Hi,
since there has been no movement on this issue for 2 years i am closing it. Feel free to reopen if necessary
Hi,
since there has been no movement on this issue for 2 years i am closing it. Feel free to reopen if necessary
Hi,
since there has been no movement on this issue for 3 years i am closing it. Feel free to reopen if necessary
Hi,
since there has been no movement on this issue for 2 years i am closing it. Feel free to reopen if necessary
Hi All,
going to close this as i've done a pile of work in 
            
              https://www.drupal.org/project/eu_cookie_compliance/issues/3552718
              
              📌
              Fix JS Code so it passes eslint test
                Active
              
             to remove the current jquery. 
it's still in beta testing, but i think it covers most aspect of what the module needs to do.
All tests passing now.
This is going into beta testing before being released to production.
This turned into a bigger change than i had anticipated.
When turning on the eslint, and cspell etc, it picked up so much jquery that would have never passed the linting test in the gitlab runner.
Instead now i have refactored this without jquery and in a much more modern format. 
Since there is such a massive change, this is going to go through some beta testing before it will be made available for production.
Hi @brahmjeet789,
Thanks for the bug report, can i ask what the contents of the disabled scripts is?
The best i can tell is that on line 831 of eu_cookie_compliance.module, the $config->get('disabled_javascripts'); is returning null? and then we apparently are passing that into the Disable JS manager. 
in which case, the empty check you are doing, should belong inside the disabled scripts manager.
Thanks!
Thanks @ronanrbr,
I'll close this now, as works as designed.
Thanks!
Hi @johnwt,
Would this issue be resolved then? I briefly saw this on another site i manage, and once i'd done a `drush updb` then it was resolved.
Thanks!
Hi Maintainers,
The issue is here Drupal\hotjar\_eu_cookie_compliance_explode_multiple_lines() ...
Eu cookie compliance module removed this function from the module in version 1.29, and pushed it into a service. A change will need to be made to accommodate this error.  In the mean time i'd recommend the users not upgrade to the 1.29 version of the eu cookie compliance module.
Thanks
Grant (eu cookie compliance module maintainer)
Hi @ronanrbr,
The problem here is that the hotjar module was calling the _eu_cookie_compliance_explode_multiple_lines() function, which technically since it has _ in front of it means it's kinda "private" to the module, so could be subject to change.
We have moved this all into the Disabled Javascript Manager service. They will need to adjust their module to accommodate this change.
I see you've created an issue on their module, i'll comment there as well.
If that makes sense i'll move this into "works as designed".
Thanks!
Hi @johnwt,
Thanks for the bug report, does a simple `drush cr` work for you? I'm trying to replicate this locally.
Also maybe a `drush updb` ?
Is the file eu_cookie_compliance/src/Service/DisabledJavaScriptManager.php present?
Thanks!
atowl → changed the visibility of the branch 3408084-add-gitlab-ci-1.x to hidden.
Hi @codebymikey
i've merged this in, thanks for the hard work on this issue.
Hi @pianomansam,
Am i correct in assuming those other 2 issues will close this one? or is this still valid?
thanks!
Hi @brahmjeet789,
I tend to agree with @rakesh.regar, i don't see this in a standard install? Is there some other plugin that prehaps is causing this? or maybe a combination of our module and another.
We'll need some more information here if i am to debug or fix this.
Thanks
Hi,
I'm not sure its been done in 1.28.
@istryker, your patch looks like it's removing the 'role' and the ''aria-describedby', but by the example you've posted, then these are actually required?
Probably more so is what is really needed here is the 'popup-text' to change it to the id of the element generating the alert dialog box, in our case that would be 'sliding-popup' ? 
Either way, this issue will need to capture that i think.
There's a few issues around this, i'll link them, need a bit more feedback on this.
Hi John_b,
No 1.x is fine, not planning a 2.x release at this stage
Hi @kieran.cott,
thanks for submitting a very detailed report, can i get you to try out the patch files from issue #3527482
See if that solves your issues, its a MR that i'm looking to merge very shortly. 
Thanks
I like this idea, will move the version to the current branch.
Didn't have it enabled and those extra bits both made it work.
Closing the issue
Hi @moshe weitzman,
Well that's good to know.
Is there any other config options with this? or just install and it works?
Thanks @adamps for the update
Closing this as won't fix, as i don't think there's anything work here to do presently.
Hi @lucky723,
Glad you have found a solution. Our site just has a link we put on a template with the correct features. eg if you scroll to the bottom of our page and look at the "Privacy settings" link. This is just defined as
<span class=.... eu-cookie-withdraw-tab ....">Privacy settings</span>
Which is picked up by the main JS of the eu cookie complaince. 
Happy to have helped you out, and I'll close this issue off now.
Hi @lucky723,
Thanks for the description update, i see what you mean now.
This isn't something i've done before so i had to dig dow a little to find it, but apparently in the drupal under structure->menu->tools there's a menu item it adds in there for cookie settings.
You can then place this block in a region to your liking.
Thanks @truls1502,
have merged this in for the next release.
Hi @lucky723,
So you can try in the settings under the "Withdraw consent" for the option "Enable floating privacy settings tab and withdraw consent banner". When saved, this will bring up a button at the bottom of the page that the user can click on and reopen the cookie selection.
Alternatively, place a link on your page somewhere with the class name "eu-cookie-withdraw-tab", this will have the same effect.
HI Jberg1,
Is still an issue?
Thanks
Both versions of php have been out for for while now and we haven't seen any other reports.
So i will assume that this issue is outdated, and therefor can be closed. 
If that's not the case, feel free to reopen.
Hi @lucky723,
Is this still an issue? Otherwise i'll close it.
Thanks!
Hi @john_b,
Is this still an issue? Otherwise i'll close it.
Thanks
Hi @adamps,
Is this still an issue? There has been no reply for a while.
Hi @taote,
Since there's been no reply in a long time i am assuming this issue to be closed
Feel free to reopen if thats not the case
Hi @deepakkm,
Appreciate the request. I am always on the look out for some help maintaining this module, but would appreciate some help in the issue queue first.
Thanks
I've re-rolled the MR160 to be up to date with the main branch,
also attached a patch for those following.
if this is acceptable we can look at merging this into the next release
Hi All,
Could i get an update for this with someone using 1.28? and if it's still a potential issue?
With no further information, i'm closing this.
Please feel free to reopen if its still an issue
With no further information, i'm closing this.
Please feel free to reopen if its still an issue
With no further information, i'm closing this.
Please feel free to reopen if its still an issue
With no further information, i'm closing this.
Please feel free to reopen if its still an issue
With no further information, i'm closing this.
Please feel free to reopen if its still an issue
Updated the module information.
Hi @John_b,
I see this as a potentially nice feature for some.
Could i get you do a basic reproduction so i could test your patch? Thanks
atowl → changed the visibility of the branch 3527482-category-scripts-fix to hidden.
Hi @jamesoakley,
I probably should document this in a better place than in the 
            
              release note →
            
To use the migration tool you should be able to do
drush en klaro_migrator
This will enable the migrator tab. 
As a good precaution, do this on a non-production environment first to make sure the results are as you expect.
I'll leave this as need more information, if it works for you then please feel free to close this as fixed.
Hi @berdir,
Could you be a bit more specific? So i could look further?
The only test it seems to be failing is the phpunit, and thats currently failing on 8.x-1.x branch as well.
Thanks
Thanks for all the work, merging this, and it'll be in the next release shortly.
Hi @eueco
Thanks for the very detailed report! I like how much information you supplied!!
I feel however, that this is probably more to do with the google_analytics module? The EUCC module isn't responsible for cleaning up the analytics cookies left behind, and if we do, that's just for the analytics cookies, what about other sites cookies?
We do provide notifiers inside the JS for other modules to hook into to see the state of categories accepted? maybe thats what you're after instead?
Very happy to discuss this further if you think we need to look into it
thanks!
Hi @guillaumeg,
I've attached a patch of the MR, if you could just confirm that works i'll look to merge it for the next release.
Thanks!
Many thanks @irafah for getting back to me on that, will closed this as fixed.
Hi @irafah
Is this still an issue for you on the later versions?
Hi @wotts,
If you modify the libraries file to look like
eu_cookie_compliance:
  js:
    js/eu_cookie_compliance.js: { minified: false }
you can debug/change your tab index, then execute `npm run uglify` to get the minified output.
Or just add your change to the issue fork, and i can take care of the minification
Hi @malirezaei
Are you still seeing this error at all with the later version of the EUCC?
If you need to debug it a bit better, you could change the eu_cookie_compliance.libraries.yml to look like:
eu_cookie_compliance:
  js:
    js/eu_cookie_compliance.js: { minified: false }
then perform a Cache clear, and it should pinpoint a better line for your error.
Closing this as a duplicate, looks like we fixed it in your other issue 🐛 Javascript cache bust variable remained constant Active
Closing this as fixed, looks like it's been merged already.
Hi All,
Merged and closed as fixed. 
Thanks for help on this issue.
For a reproduction so far i have tried
- install drupal/google_tag^1.8
- set up a new container (my_first_container), all fake-ish data and defaults.
- changed to opt-in with categories
- created 2 categories, one for my testing, and one for analytics (both unchecked by default).
- added my disabled javascripts
test_module:modules/custom/test_module/js/console_log.js|test_module
analytics:https://www.googletagmanager.com/gtag.js
analytics:sites/default/files/google_tag/my_first_container/google_tag.script.js
Now accepting the analytics category i don't see either of the two scripts pop up, however ever, applying @guillaumeg's patch, i see the both appear.
I think this is the reproduction that i'm looking for.
Hi @pianomansam,
All merged, thanks for your time on this issue!
Hi @guillaumeg, and @elaman,
I've started a 
            
              new issue about this
              
              🐛
              Javascript libraries attached in HEAD not loaded
                Active
              
            , and also attached @guillaumeg's patch to it.
We can discuss it further over there. 
Uploading the patch that was supplied in the previous issue 🐛 disabled scripts not being included after consent Active from @guillaumeg. It is the same file, just renamed to suit this issue so it can be discussed here.
Hi @joachim,
Think we need more information, and possibly a good reproduction to see whats going on here.
Hi @pianomansam
So i've spent some time going over this, and i think i've tested enough to make sure this works, just making sure since this will affect performance if we do get it wrong :)
In my ddev env turned on enough caching to get the X-Drupal-Cache to have a 'HIT' on a 2nd page refresh.
(For those playing along at home i had to use 
$settings['cache']['bins']['render'] = 'cache.backend.database';
$settings['cache']['bins']['page'] = 'cache.backend.database';
$settings['cache']['bins']['dynamic_page_cache'] = 'cache.backend.database';)
I then took your patch, and placed a log message after it, cleared the caches (drush cr), and refreshed the page.
First page load after cache clearing, i saw X-Drupal-Cache: MISS, and the log message.
Every then every subsequent page load was a X-Drupal-Cache: HIT, and no log message, as it's obviously coming from the cache. 
Is that what you were expecting/tested?
Hi @pianomansam,
Great idea. Thanks.
So just to continue on the conversation that @berdir has kicked off, if headers:DNT is now deprecated, what do we put there instead?
While I don't see an issue in continuing with this patch at present, but just wondered if there was something else to put in? at the same time, or maybe we create a new issue and deal with it there.
OK thanks for the information @pianomansam,
I'll (re) close this as fixed, and i'll look at merging #3480626, and any further disucussion in that thread.
Hi @jino matthew,
From my brief search, to meet CCPA requirements, you may need to:
-Include a “Do Not Sell My Personal Information” link.
-Provide clear disclosures about data collection and usage.
-Allow users to opt out of data sharing/selling.
-Ensure data access and deletion mechanisms are in place.
The EUCC by default goes for the opt-in strategy, where as CCPA is more opt-out from what i read.
Hope this helps.
Hi @brtamas,
With the recent releases, could i get you to check this again to see if it's still the case?
Thanks!
Hi @saarlandtoday,
Would like to help you out on this one, can you give me more information about how you're doing this? I'd like to setup a reproduction if possible.
thanks!
Hey Dan,
I'm probably not going to merge #3408084 until the whole thing is ready, as it will turn all the pipelines red. Would rather have it all working and merge it across.
I'll merge the parent into this one.
Thanks everyone for your help on this issue,
I've merged this in, will be available in the next release shortly
Hi @adriancid,
Have merged this in, thanks for your work on the issue.
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.
Hi @lmoeni
Is MR141 good to go here?
As there's no real information here, i'll close this, please feel free to reopen the issue with more information, or join us in #eu_cookie_compliance on slack for more help.
Hi @adriancid,
I've switched this across to 8.x-1.x.
Hi All,
Is the MR138 good to go? or are we still missing something?
It looks fine to me.
atowl → made their first commit to this issue’s fork.