🇩🇪Germany @szeidler

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.

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

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

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

@xenophyle I updated the MR to log the Mailchimp validation errors with a lower severity (notice).

Any kind of Drupal form spam protection can mitigate the issue, yes. In case for example the captcha catches the one that Mailchimp identifies as Spam.

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

Have you checked what is in the block. Is the content missing, is it a CSS issue?

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

Thanks for the contribution!

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

Closing, the Gin issue should fix it.

Thanks for the effort.

I can confirm that using Javascript optional chaining is solving the problem, here.

szeidler → created an issue.

Drupal 11 is most likely going to be released this week. Could we get some traction to get a D11 compatible release for Monolog?