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.
@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?
I fixed PHPCS and inverted the mercury_editor condition, which was the other way around after the PHP 7.4 compatibility change.
I can confirm: Gutenberg is working fine. I tested mercury editor as well and the updated MR brought back the submit button. But maybe one of the Mercury Editor users could give it a try as well.
No, I don't think it should be an option.
This is an error the Mailchimp API returns, that is in my opinion not an error being relevant for the Drupal site and therefore should not be logged as an error. Drupal errors should be possible to resolve from the site owner. But this validation is kind of spam-protection on the Mailchimp-side we cannot influence. A compromise that I can see is that we log the `Invalid Resource` responses with a different severity, for example warning or info.
What do you think?
@avpaderno Do you have any news?
@rachelf The patch from the beginning of the issue is only an emergency workaround, if your content editors are blocked from publishing articles.
It's not a solution for the underlying issue. A real solution is discussed in the merge request.
I committed the changes. Thanks for your inputs!
szeidler → made their first commit to this issue’s fork.
Is this a Core responsibility or just a bug in "Language Switcher Extended" module? I'm happily merging a fix for it into the module, if it's handled wrong there.
Could you have a look into 🐛 Save button missing in modal for media library Needs review and see if the MR is fixing the issue? It seems by default with the most recent Gin version the Fotoweb save button is missing and the magic cannot be fired.
I have been running into the same issue and the MR is fixing it. Also technically it seems to do the right thing for identifying a media library modal.
szeidler → created an issue.
The issue still appears for me in 6.0.6 which is identical to the current 6.0.x-dev.
@saschaeggi The changes in Gutenberg has been merged, so putting this issue to "Needs Work" to adopt the new changes.
@saschaeggi I merged in the changes. Thanks.