🇩🇪Germany @szeidler

Changing to "Needs review" to get more eyes on it.

I also can confirm it's solving the issue.

I tested the MR and it works great. Makes it possible to be compliant with CMP like Klaro

Great to hear. All the best with your Drupal experience.

I tagged a new release on the library. Could you check, that it doesn't need changes on the module?

Hi,

that's not particularly a question for this module, but a general theming question. You would need to inspect the HTML of your website, because the elements and classes are depending on the theme you're using.

On a most sites I have seen the following would be enough. But that's what you already seem to have tested out.

.language-link {
  text-transform: uppercase;
}

Yes. The cspell file is prone for conflicts. I'm using a customized version of the patch without cspell https://gist.github.com/szeidler/d951d18d4718112e7711973ed2de2469

I'm using it with Drupal 10.4

In our logs those requests are almost exclusively triggered by ChatGPT Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; GPTBot/1.2; +https://openai.com/gptbot) and similar.

Thanks for the fix. For me the change leads to another error

Drupal\Core\Render\Component\Exception\InvalidComponentException: The component "radix:table" uses non-string types for properties: rows. in Drupal\Core\Theme\Component\ComponentValidator->validateDefinition() (line 99 of core/lib/Drupal/Core/Theme/Component/ComponentValidator.php).

For me it only works if I remove the complete `rows` property.

Thanks @kensae for the implementation!

It should be possible to handle the script invocations the DFP module does (mainly via template files) .

So you would replace all

<script type='text/javascript'>

with

<script data-type="application/javascript" type="text/plain" data-name="dfp">

assuming your Klaro service machine name is `dfp`.

If that does not work out you could wrap the scripts into functions, you could call on consent given from the Klaro callback code configuration. But the first approach is the easiest, if it works.

I created a MR based on the 10.2.x branch. It adds support for Geolocation fields in Formatter + Views. The views integration is a bit hacky, because there is no easy way to identify the field type. But for someone, that needs a workaround, it should be sufficient.

The change has caused a big regression for us on translatable vocabularies. Now every taxonomy menu item is shown multiple times, one item for each translation. So one term "Research" is shown three times if the term is translated into two additional languages.

szeidler → created an issue.

I noticed the issue is already solved and released.

Oh wow, I haven't noticed this one so far.

That's for sure a big UX problem and prone to lose content changes.

There is of course the decision to do if modal or not.

One possibility without a modal would be to put Gutenberg into a "non clean state" when having the block expanded. Then the "Save" node button actually would trigger a warning and prevent saving.

Will there be a D11 compatible release anytime soon? There should not be more work than declaring D11 compatibility, because the module don't use any deprecated functionality.

I also have multiple environments missing symfony/http-client, which becomes a problem when adding a new transport type.

@adamps Could you run `composer why symfony/http-client` to see what requires the package in your setup?

I also got hit by the problem in our CI. Since views is a dependency in Gutenberg anyhow, the changes make sense.

Thanks for the effort @eiriksm

I'm also experiencing it. It seems to be related to a bug in the Gutenberg library. https://github.com/WordPress/gutenberg/issues/62072

As a workaround you can define predefined font-size as described in https://www.drupal.org/docs/contributed-modules/gutenberg/creating-custo... →

That will "fix" the problem.

I worked on a POC for the migration handling. For doing so there is a new tab on the EUCC settings page.

That tab appears for users that have access to the EUCC settings page. When you click on the form there are following permission checks

• Is the Klaro module already installed?
  • If yes, the user needs to have the "Administer klaro" permission
  • If no, the user needs have the "Install modules" permission
• Otherwise there will be an error

There is currently no summary which fields are going to be migrated or not. The reason is that simply a lot of EUCC settings or concepts are not available in Klaro and cannot be directly mapped.
Also it is currently possible to run the migration multiple times, so that potential changes in Klaro would be overwritten.

Based on @atowl 's spreadsheet I created a more structured Google Spreadsheet https://docs.google.com/spreadsheets/d/1kORGmqpzLaQ-WZ1OzLReQCeNkRKPxxN5...
It explains which EUCC settings are mapped to which Klaro settings. And if there is a special handling, how it is executed.

Major issues I encountered

You most likely will not end up with a fully functional replacement of EUCC with Klaro. The reason is that in EUCC you gave consent to purposes, but in Klaro you give it per service. Meaning after the migration the admin still needs to configure all relevant services, because in EUCC there is simply no config information about it.

Some of the EUCC are ambiguous. For example are there

• Enable floating privacy settings tab and withdraw consent banner
• Enable floating privacy settings tab after withdrawing consent

In the migration I decide to show the sticky consent toggle button if one of those options have been checked in EUCC.

• Put the "Withdraw consent" button on the cookie information banner.

In Klaro we have the same decline no matter if consent was already given or not.

But I did my best to achieve a natural mapping of the configuration.

How are purposes mapped

I'm gathering all EUCC categories. Then I gather all existing Klaro purposes. I loop through the categories and check if a purpose with the same ID or Label exists. If not, then I create it. Currently the Klaro module does not support configurable descriptions for the purposes, therefore I cannot map the former EUCC category descriptions. See ✨ Add configurable description for purpose Active

How are the banner methods mapped

• EUCC default => silent
• EUCC opt_in => notice_modal
• EUCC opt_out => notice
• EUCC categories => manager
• otherwise => notice

The EUCC opt_out one is interesting. Conceptually I would need to go through all services in Klaro and set them to `opt out` mode. But that sounds a bit drastic, because user will need to manually handle services anyhow. Currently I decided to just inform the user about the choice.

szeidler → changed the visibility of the branch 3483937-provide-a-migration to active.

szeidler → changed the visibility of the branch 3483937-provide-a-migration to hidden.

Thanks for the prompt follow up. 180 days sound like a reasonable number for me.

szeidler → created an issue.

szeidler → created an issue.

I'm assigning the task to me, because I worked a bit on a migration routine from the EUCC settings form, which seems to work fine - it's more the config mapping that is the challenge.

I will come back with a few remarks until in the next days . There are some conceptual differences between EUCC and Klaro where we might need to do some compromise decisions on the mapping of config values, because there is no obvious 1-to-1 mapping.

szeidler → created an issue.

szeidler → created an issue.

szeidler → created an issue.

For some of our migrations it also has been a breaking change. item_selector: '/' we have been able to change to item_selector: 0, which kept the desired elements selected (in our case a JSON that directly starts with an array of objects).

szeidler → created an issue.

szeidler → created an issue.

Wow @marcofernandes. This works pretty good for me and the use-case I described in the issue.

Really nice work and in my opinion works much smoother than editing block content in the sidebar.

Seems to be a duplicate of the other issue.

Thanks for your patience and the contribution.

I just merged it in, so it's available in the current dev version.

Looks good from my perspective.

I created a MR + here's the attached patch. Thanks for a review.

I second @damienmckenna. It looks like a missing dependency. I tested around with the most likely suspects. It turned out setting ckeditor5/internal.admin.image as a dependency seems to fix the error.

szeidler → created an issue.

+1 the patch is strictly necessary when using Drupal 10.3+

Note: That only ensures the D11 compatibility of this module. As long as video_embed_field will not be Drupal 11 compatible it's a bit worthless.

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

Yes, the platform synchronization is working fine with the patch. I also checked most of the DRD Drush commands, but only that they are throwing no errors/warnings.

It's mainly the prepare() and execute() method and a lot of shared properties + constructor + create. For me it felt wrong to move the constructor and create function into the trait. It would lead to typehint issues.

That's why I splitted up all the common properties and moved them into the trait as well. The class DrdPiCommands uses a reduced set of properties. class DrdCommands declares all properties that are not shared by via the trait.

What do you think?

szeidler → created an issue.

poker10 → credited szeidler → .

@goose2000 Could you check out the merge request? It is not checking for the existence of the expected method from the Core patch, rather than firing it and failing if not applied.

szeidler → created an issue.

Please see the chapter Layout Builder Support on the project page. You will need a patch for Layout Builder support.

What we can look into would be to be more failsafe if Layout Builder is just installed but not used with Block Breakpoint.

szeidler → changed the visibility of the branch 2767155-2.x to hidden.

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

szeidler → changed the visibility of the branch 3468393-custom-blocks-missing-2.x to active.

szeidler → changed the visibility of the branch 3468393-custom-blocks-missing-2.x to hidden.

I added a MR for it. I'm using the following to determine the version used

if (version_compare(\Drupal::VERSION, '10.2.0', '<')) {

I'm using that one and not the Core's DeprecationHelper, because the DeprecationHelper was also just introduced in Drupal 10.1.

szeidler → created an issue.

I created a pull request that is now merging the blocks together, if a category of mymodule_b is processed and the same category reference from mymodule_b already exists.

Furthermore – since I have been touching the code anyhow – I renamed the foreach $theme_definition to $definition to be precise, because it's actually the merged together definitions from themes and modules.

szeidler → created an issue.

Thanks @marcofernandes

szeidler → created an issue.

Thanks for sharing @freelock. Layout Builder Component Attributes seems really good.

For the ones still relying on block class for this matter, here's a patch for block_class 2.0.12

szeidler → created an issue.

Thanks for the contributions.

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

In Gutenberg 3 we do not have a style preview in the same fashion, so the problem only exists for Gutenberg 8.x-2.x

Just a note to the initial issue description: it is quite risky to run drush config:import before drush up.

If you deploy changes the best practice order is https://www.drush.org/12.x/deploycommand/ or the corresponding documented individual commands.

8.x-1.x is not supported anymore and will not receive any updates.

Thank you so much.

szeidler → created an issue.

@tkiehne This has fixed in 🐛 Undefined variable $sizes in gutenberg_form_node_form_alter() Fixed .

But I have another one as well, if you just updated without saving all node forms again.

 Warning: Trying to access array offset on null in /var/www/html/web/modules/contrib/gutenberg/gutenberg.module on line 

So it's actually better to do the following

$allowed_styles = $config->get($node_type . '_allowed_image_styles') ?? [];

In addition there is the following:

  if (!empty($styles)) {
    foreach ($styles as $style) {
      if ($allowed_styles[$style->getName()]) {
        $sizes[] = [
          'slug' => $style->getName(),
          'name' => $style->label(),
        ];
      }
    }
  }

If the site introduces a new image style after the node form has been saved, this will also lead to a warning.

Hi @avpaderno, 14 days have been passed without a response.

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

Good to have GitlabCI setup, but shouldn't we work on making the tests green?

What's the state of 2.0.x and 3.0.x now? Which version is the more modern one, active development is being made on?

Is it possible and recommended to go from 2.0.x to 3.0.x? Because if 3 is the new 8.x-1.x wouldn't it be like going backwards?

Branch 8.x-1.x will not get Drupal 11 compatible. Use 2.x instead.

szeidler → created an issue.

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

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

szeidler → created an issue.

Thanks for the contribution. It got merged in.