🇳🇴Norway @svenryen

The patch in the Drupal core issue ( https://www.drupal.org/files/issues/2023-02-06/3184569_14.patch → ) solves the bug.

If anybody wants to write a test for the core fix, it could perhaps be committed.

I found this issue in the core issue queue, which seems related.

https://www.drupal.org/project/drupal/issues/3184569 🐛 Can't translate config when source language does not exists Needs work

Please post any follow-up discussion there. There's nothing we can do in this module.

I checked, and I can reproduce in Drupal 11.0.9/PHP 8.3.12.

I'm not sure what we can do in the module, as we're not in control of the translation system.I'll see if there's a core issue for this bug, otherwise I'll create an issue in the Drupal core project.

Hi!

Thanks for the report, I was able to reproduce.

For the record, here are the exact steps:

• I installed Drupal 10.1.4 (most likely the specific version isn't needed in order to reproduce the bug) using "drush site:install"
• I installed EU Cookie Compliance, causing the module to have English settings.
• Then I installed Configuration Translation, Content Translation, Interface Translation and Language (note that we might not need all of them)
• I added French and Norwegian languages, setting French as default
• I removed the English language (this is what causes the bug to appear)
• Then I configured the site to have Norwegian as the main language, French as available for translation
• I navigated to nb/admin/config/system/eu-cookie-compliance/settings/translate

Result:

 TypeError: Drupal\config_translation\FormElement\ListElement::getTranslationBuild(): Argument #1 ($source_language) must be of type Drupal\Core\Language\LanguageInterface, null given, called in /var/www/html/web/core/modules/config_translation/src/Form/ConfigTranslationFormBase.php on line 178 in Drupal\config_translation\FormElement\ListElement->getTranslationBuild() (line 48 of core/modules/config_translation/src/FormElement/ListElement.php).
Drupal\config_translation\Form\ConfigTranslationFormBase->buildForm(Array, Object, Object, 'eu_cookie_compliance.settings', 'en') (Line: 26)
Drupal\config_translation\Form\ConfigTranslationAddForm->buildForm(Array, Object, Object, 'eu_cookie_compliance.settings', 'fr')
 

Note: Please leave the Issue Status as "Active" unless there's code to review in the issue as a gitlab branch or a patch file.

svenryen → created an issue.

Looks good, merging.

Thanks for contributing!

@codebymikey: We do want a version set (since we've had issues when there were no version set), could you add 1.26 rather than just removing the version, and then we will have an issue to increase the version counter on every new version of the module.

@leslieg just to double-check with you. Is this graphic made by you, or does it have a license that allows us to embed it in our code base?

@adriancid, thanks for helping out. Can you confirm this issue is supposed to focus on 2.x? In that case, is it also related to 8.x-1.x? We most likely will discontinue 2.x.

If you tried version 2.x, that version is unstable and will most likely be deprecated. Can you please check again with version 8.x-1.x and see if it works for you?

svenryen → changed the visibility of the branch 1.0.x to hidden.

I would say that if a site migrates to Klaro then the consent banner should be shown again. My reason is that the site has changed consent managers, so this, in my opinion, is almost like changing privacy versions.

I still disagree. If you have the same cookie categories, and the privacy statement doesn't change, there shouldn't be any need to display the consent banner again.

Maybe we could have a section about this on the "Migrate to Klaro" page. The summary/gap analysis we've been discussing could conclude that there are either 1) no changes when moving to Klaro or 2) Klaro won't have the same configuration; list the actual changes.

If there are no changes, we can have a section that says something like "We've identified that the migration can migrate the settings in Klaro, do you still plan to update your privacy policy?" with a "Yes" or "No". If it's a "No", we display a checkbox "Do not show the consent banner/options again after migrating". Then the site owner can decide not to show the banner, in the case where the settings and categories will be identical in EU CC and Klaro.

svenryen → created an issue.

The spreadsheet opened without problems in Excel, so it seems fine that it's an ods.
Possibly it could also be imported in Google Sheets.

When briefly looking at the gap analysis, what I'm not sure we've covered is the cookie format (the actual consent storage where consent is stored as well as with categories).

If we're able to transfer most of the settings, and the privacy/categories remain the same, it would be fantastic if the end user/site visitor doesn't have to give consent again.

Consider the scenario:

• I visit the site in november 2024
• The site mogrates to Klaro in January 2025
• The site should still know what I consented to and not display a cookie consent banner/button again

Since this is important, should we move it to a separate issue here in the queue?

Thanks for the contribution, we'll have a look in November.

We're also in an exciting process to make privacy really great in Drupal Starshot/CMS, and there's a whole team working on that. The work involves a migration path from EU CC to Klaro. You can read more about it in the migrate to Klaro issue ✨ Provide a migration path to Klaro Active .

Sven, could we just provide a migration a button from the /admin/config/system/eu-cookie-compliance area?

Thanks for the analysis work. I'll take a look at the spreadsheet later.

This is what I've proposed, and have approval from module sponsors that they can help fund: What we want is a separate tab in EU Cookie Compliance admin, named "Migrate to Klaro", where we briefly explain what's going on (the TL;DR), lay out the gap analysis of what settings will remain the same (based on your spreadsheet) and what will be different in Klaro. Perhaps also some hints to how to transform custom CSS styles that they may have applied in EU CC.

Then, when the site owner has read and digested this information, they can click a button (as you say) to Migrate to Klaro.

What will then happen could be something like this:

1. enable the Klaro module
2. migrate the settings from EU CC to Klaro
3. there was a suggestion that we should disable the EU CC module. When giving it some thought, I think it's best to leave EU CC enabled, but restrict it's functionality to a tab saying "Revert to EU Cookie Compliance", which is in place of the "Migrate to Klaro" tab that will be hidden after the migration is complete. No banner will be shown from EU CC and the javascript wil not be embedded, unless they decide to revert.
4. after migration, if they like the new module, they can manually uninstall and remove EU CC from their site, with the EU CC admin page displaying instructions for how to uninstall the module manually or with composer

A notice banner that shows up (but without being obtrusive) guiding the site admin to the new tab could also be considered. Perhaps it can show up and then be possible to dismiss if they decide not to follow the recommendations.

The plan is that a mockup of the functionality will be available on Monday. Ramsalt will also pull from our resources and make a developer or two available to work on this in November, but you're most welcome to help out.

Let me know what you think.

Here's another reason we might not want to automatically convert their setup of EU Cookie Compliance into Klaro config and uninstall the EU CC module:

CSS styles.

Although you probably have site builders that only change the colors of the banner and the text and leave the default CSS which we can easily carry over to Klaro. However, it's common for sites in the enterprise end through to professional websites to enforce that everything should be based on their corporate design guidelines. In other words, they've customized not only the banner colors but also the typography and other aspects of the banner. And if it wasn't complicated enough, we have got several CSS styles in EU Cookie Compliance (since some people wanted a more modern look and feel to go with the Oliviero theme).

Unless we come up with some fancy way of reading their theme CSS (which I think will be a nightmare to code for) we really should follow what I referred to above as an informed opt-in action acknowledging what will happen and perhaps also with a crash course in how to style Klaro, so that they can prepare a style sheet where the banner still looks great (whether they want it to look like it did in the past of leverage the features of Klaro to make it look even better), then they can follow whatever process they have to stage stage that, test it, have their management accept it, and make the move once they're ready. Fewer things can go wrong when the upgrade is just a tad less automatic.

I'm just thinking out loud here, we should provide the best experience when moving over to Klaro, and there might be other reasons beyond the ones I mention here that call for an upgrade path that doesn't just happen automatically.

So if I understand your comment, you would want to see us have a version 2 of this module that in itself doesn't do much beyond displaying an interface and then performs an automated conversion to Klaro as soon as they type the composer command?

No banner or features at all, just a conversion to Klaro without any easy way for site builders to return to Eu Cookie Compliance once they've upgraded to version 2.0, which they then have to remove? (Just assuming there will be sites using this feature that are not up to speed on Drupal and its latest offering in terms of Drupal CMS. They might end up a little bit confused if it all happens automatically. I haven't seen any other module that automatically uninstalls itself as part of an update, so I wonder what's the best practise?)

Are we sure that Klaro caters for all the edge cases that this module offers? How do we handle those that by accident installed version 2 only to find out their favorite feature is missing and then feel left out?

A different approach would be to make the conversion happen by pressing a button to confirm the migration action. Then we can let the migration take part in the 1.x version code base, and we would be able to carry over far more sites to Klaro.

We would also be able to display some kind of report, say as a separate tab, where they can make an informed decision, and see what features they have configured in EU Cookie Compliance will be covered by Klaro (assuming we don't replicate the feature set from EU Cookie Compliance in Klaro). Sort of like a gap analysis that they opt into rather than stumble upon by accident when they thought they were going to get the latest and greatest from a module they're familiar with.

As part of the report page where they confirm the upgrade, we can also point out the benefits of Klaro, the downsides of staying on EU Cookie Compliance (no updates besides critical bugs fixes and issues that are RTBC) to entice them into moving their config over.

svenryen → created an issue.

svenryen → created an issue.

Merged. Thanks for the contribution!

I reverted till we've understood why this leads to a CI error.
Most likely those are all tasks discovered while linting the code, so we need a separate issue where we fix them.
I don't want to add code that causes errors in the build reports.

Please disregard the many open/closes, I was having an issue with my network connection.

svenryen → changed the visibility of the branch 3408084-add-gitlab-ci-1.x to active.

svenryen → changed the visibility of the branch 3408084-add-gitlab-ci to hidden.

svenryen → changed the visibility of the branch 3408084-add-gitlab-ci to hidden.

svenryen → changed the visibility of the branch 3408084-add-gitlab-ci-1.x to hidden.

svenryen → changed the visibility of the branch 3408084-add-gitlab-ci to active.

svenryen → changed the visibility of the branch 3408084-add-gitlab-ci to hidden.

@vipin.mittal18 nice work, thank you! I have one comment /request. Could you update the MR to remove all the unnecessary commented lines, including the Drupal ASCII art?

Thanks for the contribution. I'll merge this later and tag a release.

Thanks @ericvl. I should have tagged a RC some time today or tomorrow.

Hi Rajeshreeputra, Vipin.mittal and Chandu and all!

I haven't forgotten this, just been busy since coming back from vacation.

This needs more work:

Have you explored?https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Render%21... ?

I think it might be the best approach, so we can have a dependency on the library in D11 and not in the previous versions.

I'll get back to you on this, hopefully this week.

@ Rajeshreeputra:

@svenryen could you please tag the issue needed for 2.x release

Well there isn't a single issue for 2.0.x per se. Any contribution on 2.x would be appreciated. I can work with your team on that after my summer vacation (it's vacation time in Northern Europe).

Any chance we can discuss involvement for D11 on Drupal Slack?

@deepakkm and @mishradeepak1991, could you please help clarify what will happen if the js_cookie module isn't available?

In D11, we shouldn't allow the module to work (so display some kind of notice about the lack of the js_cookie module) if the js_cookie module isn't there. At the same time, we probably shouldn't install the module in D8.9.x (if this is relevant).

Thanks for the patch. I'll take a look.

@Rajeshreeputra I hear you, but there will take some time to deliver a version 2.0.x, and it won't be ready for Drupal 11 release unless somebody has a lot of time to devote to that task before August. Also taking into consideration, we want a complete rewrite of the JavaScript and other functionality in version 2.0.x.

> Let's maintain the 1.x branch to support Drupal 8, 9, and 10 versions, ensuring broader compatibility.

I would like to modify the merge request in this issue so as to support versions 8.9.x through 11. Anybody can work on this if you have time, or I will look into it before August.

@heddn, @ankithashetty, thanks for the contribution to v2.0.x!

This should be possible to merge (although v2 essentially does nothing at this point and can't be used), and the plan is to rewrite the code and abolish the need of js_cookie:js_cookie in version 2.0.x, or should I close it, leaving a mention that it's obsolete?

Should we leave this issue open and conclude something so that it doesn't get merged later on?

Hi all!

Thanks for teaming up to improve the a11y functionality of the cookie banner.

I see that the code changed from (supposedly) saying that the label for the element can be found in the DOM element with the ID "popup-text", to a text string.

This removes the connection (if there ever was one) between "sliding-popup" and "popup-text". and introduces a new string with the content of "Popup text".

I need to check with somebody that is familiar enough with Web Accessibility to check if this is a desirable outcome.

@heedn, I see you rerolled the patch from https://www.drupal.org/project/eu_cookie_compliance/issues/3379830#comme... 🐛 Elements with role="dialog" or role="alertdialog" do not have accessible names Needs work and didn't take into consideration the code contributed in https://www.drupal.org/project/eu_cookie_compliance/issues/3379830#comme... 🐛 Elements with role="dialog" or role="alertdialog" do not have accessible names Needs work where an improvement was attempted. Could you either work to improve this, or let us know the logic behind this change?

I'm also wondering if the final merge request does what's best for accessibility, or if we need to cosunlt somebody that has accessibility as a field of profession. Are we okay that the functionality presumably changes from saying that the string is in #popup-text or do we want a generic "Cookie Privacy Banner" to be added?

@Pravin Gaikwad. Thanks for your contribution. I have some remarks, if these are resolved, we can consider accepting the Merge request.

I see in #9e8ba1a9 that you've changed core_version_requirement to exclude Drupal 8.9.
(https://git.drupalcode.org/project/eu-cookie-compliance/-/merge_requests...)
I see that the usage of Drupal 8.9.x is at 29,738 websites as of July 6th, and we have around 56,007 sites that use version 8.x-1.x of this module. I would like to be able to continue supporting sites that are on versions 8.9, 9, 10 and 11 of Drupal. A possible scenario is that (although unlikely) we could come across a security issue at some point in the future, and with the restrictive core version requirement. It would then be challenging to effectively offer those who are using Drupal 8 a quick path to the new version. Requiring that people update to Drupal 9 in such a case may not be the best option.

It should be possible to offer a soft dependency of https://www.drupal.org/project/js_cookie → so that those on Drupal 8 can continue using the core library and the later versions require the js_cookie module.

I also see in #82398ac5 that the code makes an assumption that js_cookie has been downloaded but perhaps not enabled. How does the code handle the case where the js_cookie module hasn't been added to composer.json? At the least we should present the user with some message explaining that the js_cookie module needs to be added. I'm not sure if we have a pattern for this use case that we could adopt.

Takk for møtet!

svenryen → changed the visibility of the branch 2546212-entity-viewform-mode to active.

svenryen → made their first commit to this issue’s fork.

As a non-ideal workaround, you can paste this command into the browser console:

jQuery('.paragraphs-add-dialog input').show(). After running this, the "Add above" choice works.

Maybe this can help nail down the bug and come up with a patch.

I did some testing. This bug doesn't show with the Seven theme. The site in question uses Claro.

The problem is that somehow the buttons that should be available in the "Add [paragraph]" or "Add above" buttons gets an inline style of display:none.

We arrive at this situation when there's a Reusable paragraph that contains a list of paragraphs.

Grienauer → credited svenryen → .

svenryen → changed the visibility of the branch 3408193-z-index-of-ui-dialog to active.

svenryen → changed the visibility of the branch 3408193-z-index-of-ui-dialog to hidden.

svenryen → created an issue.

This patch probably won't make it into core, due to the lack of a test.

I'm adding it here, since we saw additional fatal crashes in another file where in_array() was being used on a NULL value, and it might help others facing the same bug.

Fixed.

Merged. Thanks for contributing!

Thanks! Code is looking good.

svenryen → created an issue.

I've gone through the code for D7 and D8/9/10 and I can't see any situation where we would pass null to any parameter of the preg_* functions.

So I'll close this one for now. Feel free to reopen if you disagree.

svenryen → created an issue.

svenryen → created an issue.

I'm changing this to a feature request.

@kle,

I'm not sure I follow. From what I recall, $is_script and $is_src refers to two different script types, and won't be present together.

That slash has been prepended since 2020, and is working properly on my installs and apparently for 50000 users of the module. Do you have an example here? Could you make a custom module to demonstrate what you think is wrong, and upload that one to the issue ans a zip package?

There's some instructions here:

https://www.drupal.org/project/eu_cookie_compliance/issues/3254826 🐛 Disabling Javascript with "Opt-in with categories" enable seems to not work Postponed: needs info

Basically you need to examine files and libraries from the module that you want to prevent loading scripts, and use the file paths that you can find in the page's source, excluding the leading slash.

I'm not the most experienced GTM/GA user, but I did set up an account at https://tagmanager.google.com/#/home and https://analytics.google.com/analytics/web/.

Best practice nowadays seems to be using the google_tag module, so I installed, enabled and configured that module to load my GTM tag.

Once that's set up and confirmed working, I set up my site to Opt-in users to tracking and listed the two scripts of the google_tag module in "Disable JavaScripts".

The value of the field is:

<blockquote>modules/contrib/google_tag/js/gtag.js
modules/contrib/google_tag/js/gtm.js</blockquote>

I also tried the same setup with a category added to the mix:

<blockquote>analytics:modules/contrib/google_tag/js/gtag.js
analytics:modules/contrib/google_tag/js/gtm.js</blockquote>

Loading that page in a few incognito windows demonstrates that there's no GA traffic recorded until the consent was given, and after it was given, the googletagmanager script loads and records my activity in GA4.

It seems this module doesn't create a sites/default/files/google_tag/google_tag.script.js file. Could you add some information as to what module provides that file? Is it possible to attempt using the google_tag module to achieve your desired outcome, or is there some feature google_tag lacks?

Hi again, @crmn.

I did some minimal attempt at reproducing, but given that there was no product named "AdBlocker" for Chrome (that I could find), I'm a bit short on this one.

I did try to install AdBlock (the Chrome plugin) but I din't want to pay a premium to get the cookie consent automation. I also found AdBlocker Ultimate, but that plugin didn't have any feature that I could see to work with cookie banners.

So I'm a bit lost. I'd be happy to provide a better experience if you could name the product you're having issues with and provide a clear list of steps to reproduce.

I see your proposed solution, but I'd like the patch to be testable. I might take a look again later, but for now I'll mark this issue as "Postponed"

@Ambient.Impact, could you provide steps to reproduce?

I'm at 10.1.5 with JS and CSS aggregation enabled, and I don't get this error.

svenryen → created an issue.

Merged. Thanks for contributing!