'filter.format.' . WebformHtmlEditor::DEFAULT_FILTER_FORMAT missing UUID

See 🐛 Querying with NULL values results in warning mb_strtolower(): Passing null to parameter is deprecated Needs work for what this causes.

I did not have time to reproduce the issue but the attached patch might address the root cause which is don't alter config when config is being sync'd

I get the following with the patch in #4:

1) Drupal\Tests\install_profile\Functional\InstallProfileTest::testInstall
editor.editor.webform_default: Drupal\Component\Diff\Engine\DiffOpChange::__set_state(array(
   'type' => 'change',
   'orig' => 
  array (
    0 => 'uuid: null',
  ),
   'closing' => 
  array (
    0 => 'uuid: 94ff9c7f-4743-4b76-a020-5d83cf93b3ba',
  ),
))

I got no error with the patch in #2.

I am open to patch #2, I am assuming the filter.format.webform_default does get assigned a UUID.

If you assign a UUID in your exported config, it will get overridden when the exported config is executed. Ideally #2 would assign a unique UUID to the config as it is inserting into the DB. Otherwise, it is gets inserted as a null value and site admins have to ignore the warnings from #3.

Moving this to critical because it should be a release blocker.

@hedden I am fine with your recommendation from #4.

I am changing this to RTBC so that https://www.drupal.org/files/issues/2023-06-23/3369127.patch → can be merged.

The real issue here is that _webform_update_html_editor() is using the config storage directly to write the config and thus leaving the config without an UUID. We identified this since we use the config_plus → module that has a protection against saving configs without an UUID. The UUID is being added to an entity only when using the entity storage to save the entity. Therefore we should not be using the config storage here to create config entities but rather the config entity storage. I am attaching a patch that properly installs the config entities.

@hchonov Thank you for swopping in and saving the day. Your patch looks fine to me.

Automatically closed - issue fixed for 2 weeks with no activity.