🇳🇴Norway @svenryen

Hi @danrod! I am sure your contributions to this module would be helpful. Could you please follow up with @atowl regarding becoming a co-maintainer? I left the project due to health reasons, and I'm not able to add you right now.

Since there are comments left in the issue, I'm setting status to Needs work.

I'm setting the issue to Active again in case there are more people interested. Feel free to close it when we reach May.

For the record, @rajeshreeputra asked to become a maintainer in the linked issue.

Great, I've added you. Feel free to add more maintainers.

I have made a spreadsheet with a proposed list of issues to include for a bug release. https://docs.google.com/spreadsheets/d/1W_drf90rqJpFkSOxMjR3tKwhJaY5mj0P...

Just confirming what @jurgenhaas mentions in Comment 2: The "General Data Protection Regulation (GDPR)" module really handles other aspects of data protection than EU Cookie Compliance, and I think for some use cases the GDPR module is still useful even when Klaro! is being used. I wouldn't recommend saying that Klaro! replaces the GDPR module.

When it comes to EU COokie Compliance, we are doing what we can to deprecate it, but we have to do it the right way, and that takes time. Hopefully, by the end of May we should have reached a final conclusion about the fate of the EU Cookie Compliance module.

I have started today by posting that the EU Cookie Compliance module is looking for a new maintainer 💬 Seeking new maintainer for EU Cookie Compliance Active . I have read the docs on drupal.org quite in detail this morning, and it seems that making the announcement is the best practice and first step. If nobody shows interest, we're prepared to mark EU Cookie Compliance as Unsupported by the end of May.

svenryen → created an issue.

svenryen → created an issue.

Added a notice that Klaro is being favored.

Added a notice that Klaro is being favored.

Thanks for the report. We will take a look.

Actually, when I review your code, I see that it needs work.

From what I understand (after a very quick glance), the patch causes the banner to be delayed by 5000 ms on every site of which the module is used.

It would be better if the delay could be configured by the administrator. For sites where they do not desire to delay the banner by a fixed amount of time, they could set the value to 0 (which should be the default value) to indicate that they don't want to implement a delay.

Those who want a delay can set it to 5000 or any other value.

Thanks for the contribution @ooa33. Let's see if we can find somebody to review it :)

Following up this issue. Can it be remedied in Drupal, or is this related to https://github.com/klaro-org/klaro-js/issues/100 ?

Reopening this issue after comment from @pianomansam.

@pianomansam and @fholub13, I see that you're referring to Merge request 150.

The merge request in 150 seems to delete some lines, so until that's been explained, I'm afraid this one will have to wait.
Do you happen to know the reason for the removal of a few lines, as mentioned here 🐛 DNT (Do Not Track) header detection not working when caching enabled Active ?

Hi!

Thanks for helping.

Could you please explain the reason for the removal of line 156-179?

If it's ok for you, I'll change the version to 1.x.

We're deprecating 2.0 since we're supporting the Klaro! initiative.

I updated the Drupal.no slack URL since the old one lead to a site that we discontinued.

The Drupal code base uses a library called Prophesize to facilitate mocking objects, whereas the documentation refers to Mockery only. I think the docs should also mention Prophesize, maybe also removing Mockery to not confuse people.

It probably should point here: https://new.drupal.org/docs/drupal-cms/get-started/install-drupal-cms/mo...

First of all! Great work with Drupal CMS and the kickoff! This really rocks!

I'm not sure if this is the right venue for reporting issues with the new content on drupal.org, but I've found that the "move your site to a hosting provider" link on this page leads to a 404:

https://new.drupal.org/docs/drupal-cms/get-started/get-to-know-drupal-cm...

The plan was to present the user with some sort of report saying:
- here are the config items from EU CC that map over and can be converted automatically to Klaro.
- here are the ones which do not map.

And then that should be presented on a new tab named "Migrate to Klaro" so that they can choose what to do.
Does that make sense, @szeidler?

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.