@dk-massive

🐛 | Metatag | Errors in field configuration can lead metatag_post_update_remove_robots_noydir_noodp() to fail

@damienmckenna: sure thing
This to create a field that has nothing in it but a key you set. Adjust the 'page' to match a content type. In my case it was a paragraph type. I am not sure if it needs to be a field that existed before but was already deleted.

$config_factory = Drupal::service('config.factory');
$config_factory->getEditable('field.field.node.page.field_my_fake_field')->set('foobar', TRUE)->save();

You can use drush cget to check it in your terminal:
drush cget field.field.node.page.field_my_fake_field

You should see a config with nothing but that key you set.

This is what I used to clean it up on the sites I found:

$config_factory = Drupal::service('config.factory');
  $list = $config_factory->listAll('field.field');
  $fields = $config_factory->loadMultiple($list);

  foreach ($fields as $field) {
    if (!$field->get('field_type')) {
      $editable_config = $config_factory->getEditable($field->getName());
      $editable_config->delete();
    }
  }

I figure it is safe to remove any field configs without a field_type.

I hope this helps. Again my case was caused by paragraph fields, in case that is relevant.

🐛 | Metatag | Errors in field configuration can lead metatag_post_update_remove_robots_noydir_noodp() to fail

It was indeed a misconfigured config entity.

In our case the site had custom update hooks to modify existing content entities. These hooks used the ConfigFactory->getEditable method to load them and change them. The getEditable method creates a new config entity if one with the name provided does not exist, so in those cases the update hooks had created config entities with just the keys they were modifying.

🐛 | Metatag | Errors in field configuration can lead metatag_post_update_remove_robots_noydir_noodp() to fail

  array:1 [
    "Failed record:" => ""
  ]
  array:1 [
    "required" => true
  ]

This is what is dumped when the update hook fails.

I am not the original poster, but am encountering this same exact issue with the update hook.

here is the output when running that command:

>>> \Drupal::entityTypeManager()->getStorage('field_storage_config')->loadByProperties(['type' => 'metatag']);
=> [
     "node.field_meta_tags" => Drupal\field\Entity\FieldStorageConfig {#9535
       +custom_storage: false,
     },
   ]
>>>

I went ahead and put up the MR to start getting this reviewed as it does make the module compatible with Ckeditor5. I feel like this is the priority since this module can become a blocker from moving existing sites over to Ckeditor5.

I want to get the dialog form converted to a Ckeditor5 balloon panel similar to how links work, and am happy to help with that. I will have more time later this week to do so.

Here is a patch with the Ckeditor5 plugin for people to test.

Yes still woking on this

some notes:

The structure being upcast and downcast has the i or span tag wrapped in a span with the class "fontawesome-icon-inline". I did this to match what was being written to the view by the ckeditor4 plugin. I am not sure if we need to cover cases of icons without this wrapping span.
I am inserting the span/i tag into the editor as a rawElement. I did this due to having a lot of issues with inserting a child element with a class. I am then making the icon a widget when downcasting to the editing view so you can manipulate the icon in the editor.
The Ckeditor5 plugin created here is still using the same Drupal dialog form as the Ckeditor4 plugin. I would like to get it converted over to a Ckeditor5 balloon, but the existing Drupal dialog form works well in the meantime. It would also be great to make the icons editable widgets that can have their attributes modified through the same balloon form.

I started an issue fork and have a mostly working ckeditor5 plugin created on the "ckeditor5" branch of the fork.

It seems to be working for the most part. Icons come through when I switch between a ckeditor4 text format and a ckeditor5 text format.

One thing it is not doing: I simply will not insert the icon when in source mode. It does not remove them when switching source mode on and off, but it will not create them while in source mode.

I working on adding the svg conversion to the plugin now.

dk-massive → made their first commit to this issue’s fork.

🐛 | Drupal core | Layout builder does not protect against recursion

fix test. adjust test to use prophesize for logger service.

🐛 | Drupal core | Layout builder does not protect against recursion

🐛 | Drupal core | Layout builder does not protect against recursion

fix testing issue

🐛 | Drupal core | Layout builder does not protect against recursion

Fixed test issue.

📌 | Purge file | Automated Drupal 10 compatibility fixes

Any chance we can get this into a Drupal 10 compatible release?

📌 | Fixed text link formatter | Automated Drupal 10 compatibility fixes

Applying the patch will not change the dependencies that are declared in the packagist package, so you will still get a dependency conflict when trying to require the module in a composer file that is using drupal core 10.

The only way I know around that would be to commit the module into your repository with the patch applied and remove it from composer.

----

Is anyone still maintaining this module? Could we get this into a Drupal 10 compatible release?

🐛 | Drupal core | Layout builder does not protect against recursion

In a site I am managing, patches 65 and 69 causes Paragraphs using Layout Builder in their view mode to not render their content.

📌 | Field Delimiter (Multi Value Field Formatter) | Automated Drupal 10 compatibility fixes