## Problem/Motivation The recipe can't be applied to a site that already has a `body` field storage of type `text_with_summary` but no body field on the Event content type. That's the normal state of a site built with the Standard profile or with core's `page_content_type` or `article_content_type` recipes, which still use `text_with_summary` as of Drupal 11.4. ``` In RecipeConfigInstaller.php line 70: There were validation errors in field.field.node.event.body: - settings: 'display_summary' is an unknown key because field_type is text_long (see config schema type field.field_settings.text_long). - settings: 'required_summary' is an unknown key because field_type is text_long (see config schema type field.field_settings.text_long). ``` The recipe ships `field.storage.node.body` as `text_long` (#3591707), and strict checking on that storage was removed (#3606743), so the site's existing `text_with_summary` storage is kept. The shipped `field.field.node.event.body.yml` still hard-codes `field_type: text_long`. When that field is saved, core adds the default settings for the actual storage type (`text_with_summary`), and config validation then rejects them against the declared `text_long` type. The failure also happens when the recipe is pulled in by another recipe, such as Events Calendar. ## Steps to reproduce 1. Install Drupal 11.4 with the Standard profile, or apply `core/recipes/page_content_type`. 2. Confirm `field.storage.node.body` has `type: text_with_summary`. 3. Apply the Events recipe (directly or through Events Calendar). 4. The validation error above is thrown. Sites with no existing `body` storage, or with `text_long` storage, apply cleanly. ## Proposed resolution No single static field config works for both storage types, so let core work out the field type from whichever storage exists: - Remove `config/field.field.node.event.body.yml`. Create the field instead with a `createIfNotExists` config action in `recipe.yml` that leaves out `field_type`. Entities created through the action go through `postCreate()`, which fills in `field_type` from the storage. Removing `field_type` from the static YAML file doesn't work: config import doesn't fill it in, and it fails with `The "" plugin does not exist`. - Remove the `body` component (and the `field.field.node.event.body` and `text` dependencies) from `core.entity_form_display.node.event.default.yml`. Add it back with a `setComponent` action that sets no widget `type`, so core uses the default widget for the field type. Without this, the body widget is silently dropped from the form, because `text_textarea` isn't valid for `text_with_summary`. - The view displays (`text_default`, `text_trimmed`) support both field types and don't need changes. ## Remaining tasks - [ ] Review the proposed changes - [x] Test on a site with existing `text_with_summary` body storage (Drupal 11.4.11): applies cleanly, can be re-applied, and the form gets the `text_textarea_with_summary` widget - [ ] Test on a site with no existing body storage (for example a Drupal CMS site template such as Byte) - [ ] Consider automated test coverage for both storage types ## User interface changes None. Event forms use the widget that matches the site's body field type. ## API changes None. ## Data model changes The Event body field now matches the site's existing body storage type, so it may be `text_with_summary` rather than always `text_long`. --- I've referenced the related issues as plain `#3591707` and `#3606743`. Swap in full links if they don't auto-link on GitLab.