🇳🇴Norway @svenryen

I couldn't make the code from the issue branch apply to 11.2.5, so here's a patch for that version

I couldn't use issue fork, since this code needs to be applied on top 2985168: Allow media items to be edited in a modal when using the field widget .

Attached is an updated patch that works with Drupal 11.2.5.

svenryen → created an issue.

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

I second the comment in #4

Since we also have a Drush command serving the same purpose, we don't need a command for Drupal Console.

svenryen → created an issue.

Thank you, @grumpydev74
I'm not actively maintaining this module, but I presume the other maintainers will follow up.

@simonbaese, could you please help re-roll this branch?
(Sorry for late reply) 😃

@grumpydev74 - I reviewed the MR. It seems to duplicate fixes for several issues that were already merged. Could you help with a re-roll so that it can be merged?

Looks good, thanks for contributing!

Having manually read the reg ex, this one looks good to me. Thanks for contributing!

Thanks for contributing!

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

Would have preferred a strict comparison to 0, but let's go ahead with this - RTBC

RTBC. Looks good to me.

I'm trusting the RTBC and merging the patch

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

svenryen → created an issue.

svenryen → created an issue.

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.