The "moderation_state" base field overrides cause install from existing config to fail

Updated patch with just a new config archive (the previous one was not sorted correctly). Please review

Those config archive are hard :)

Hm, I think test with fixtures should go to the module

The last submitted patch, 48: 3129874-48.patch, failed testing. View results →

Per #39

Should we find a way to throw an exception when a base field override is created, to prevent these leaking into installations in other ways? If we're doing this, it'd be nice to confidently say: there is never a BFO for any CM field, on any installation.

Do we need an update hook to delete the existing ones?

We're missing test coverage that asserts the option is missing from the UI and no BFO entities are created when submitting the UI.

Don't think these have been answered yet.

I updated the patch for the Drupal 10.3.x compatibility. Thank you!

Last patch doesn't fix the issue.
Currently this issue only gets fixed if we manually remove `*.moderation_state.yml` from config folder. We might need new patch to fix this issue.
I've checked in 10.2.x version.

#54, see #37, the current patch only prevents moderation_state BFOs to be exported. Existing ones need to be removed manually.
Let's not continue with patches and create a merge request.

I'm wondering if this shouldn't maybe be fixed on a more dynamic scale for every computed field. Because we currently have the same problem with other fields and they all have ->setComputed(TRUE) in their bundleFieldDefinition.

So, shouldn't we maybe go with something like this in the after build:

  foreach ($form['#labels'] as $entity_type_id => $label) {
    foreach (\Drupal::service('entity_type.bundle.info')->getBundleInfo($entity_type_id) as $bundle => $bundle_info) {
      foreach (\Drupal::service('entity_field.manager')->getFieldDefinitions($entity_type_id, $bundle) as $field_name => $field_definition) {
        if ($field_definition->isComputed()) {
          if (isset($form['settings'][$entity_type_id][$bundle]['fields'][$field_name])) {
            unset($form['settings'][$entity_type_id][$bundle]['fields'][$field_name]);
            $form_state->unsetValue(['settings', $entity_type_id, $bundle, 'fields', $field_name]);
          }
        }
      }
    }
  }
  return $form;

We might rename that issue then to "Prevent the creation of base field overrides for computed fields"

We might rename that issue then to "Prevent the creation of base field overrides for computed fields"

But I'm not sure, as this seems to also hide much more fields than just problematic ones. For example now also URL alias and menu link are hidden.

Hm, that brings me to the point to question myself: What is special about that content_moderation field, while other computed fields work just fine? 🤔

What is special about that content_moderation field, while other computed fields work just fine?

See #2321071-42: BaseFieldOverride fails to take into account ContentEntityInterface::bundleFieldDefinitions() when invoking onFieldDefinitionUpdate() → + this issue description.
It's convoluted...

The way we solved it now is mimicking other unproblematic computed fields like metatags, providing a new field type with an empty schema:

public static function schema(FieldStorageDefinitionInterface $field_definition) {
  return [];
}