<!-- Cannot set labels as a non-member. Suggested triage: --> **Suggested labels:** `category::bug` · `priority::normal` · `v1.x-dev` · `code` **Affected version:** 1.0.0-alpha4 and 1.x HEAD (identical for this file) **Tested on:** Drupal 11.4.6, PHP 8.4 ## Problem/Motivation `group_features.schema.yml` defines `field.value.group_features`, but neither `field.storage_settings.group_features` nor `field.field_settings.group_features`. `GroupFeaturesItem` extends `EntityReferenceItem`, so it inherits the entity reference settings on both levels: `target_type` on the field storage (explicitly set to `group_feature` in `GroupFeaturesItem::defaultStorageSettings()`), and `handler` plus `handler_settings` on the field instance. Without the two schema definitions above, those settings resolve to the fallback types `field.storage_settings.*` and `field.field_settings.*`, which are empty mappings that allow no keys at all. Since `field_storage_config_base` and `field_config_base` are marked `FullyValidatable` in core, both configs for a `group_features` field now fail validation: ``` field.field.group.community.field_features:settings: 'handler' is an unknown key because field_type is group_features (see config schema type field.field_settings.*). field.field.group.community.field_features:settings: 'handler_settings' is an unknown key because field_type is group_features (see config schema type field.field_settings.*). field.storage.group.field_features:settings: 'target_type' is an unknown key because type is group_features (see config schema type field.storage_settings.*). ``` This makes it impossible to ship a preconfigured features field in a recipe, a config export, or an install profile. It surfaced while installing the [OGCB](https://www.drupal.org/project/ogcb) site template, whose recipe ships both `field.storage.group.field_features.yml` and `field.field.group.community.field_features.yml`. ## Steps to reproduce 1. Install `group_features` on Drupal 11.4. 2. Create a `group_features` field on a group type through the UI. 3. Export the configuration, or write the two configs by hand: ```yaml # field.storage.group.field_features.yml langcode: en status: true dependencies: module: - group - group_features id: group.field_features field_name: field_features entity_type: group type: group_features settings: target_type: group_feature module: group_features locked: false cardinality: -1 translatable: true indexes: { } persist_with_no_fields: false custom_storage: false ``` ```yaml # field.field.group.community.field_features.yml langcode: en status: true dependencies: config: - field.storage.group.field_features - group.type.community module: - group_features id: group.community.field_features field_name: field_features entity_type: group bundle: community label: Features description: 'Enable features you want to use for your community.' required: false translatable: false default_value: { } default_value_callback: '' settings: handler: 'default:group_feature' handler_settings: target_bundles: null auto_create: 0 field_type: group_features ``` 4. Import them via `drush config:import`, a recipe, or a module's `config/install` directory. Result: validation fails with the three violations above. The same configuration saves fine through the UI, because the entity form does not run config schema validation on the resulting settings — the problem only appears once the config passes through the validation pipeline. To verify without a full import, validate the stored config directly: ```php $name = 'field.field.group.community.field_features'; $violations = \Drupal::service('config.typed') ->createFromNameAndData($name, \Drupal::config($name)->getRawData()) ->validate(); ``` ## Proposed resolution Point both settings types at their entity reference counterparts, mirroring what the field type already inherits in PHP. ```yaml field.storage_settings.group_features: type: field.storage_settings.entity_reference label: 'Features field storage settings' field.field_settings.group_features: type: field.field_settings.entity_reference label: 'Features field settings' ``` With this in place both configs validate with zero violations. Nothing else changes — no update hook is needed, since this only adds schema for settings that were already being stored.