Problem/Motivation

Display Builder ships its default profile (display_builder.profile.default.yml) and text format (filter.format.display_builder_html.yml) as config/optional. Recipes only install config they explicitly list, so a recipe that installs Display Builder without also importing these two configs ends up without the default profile.

Steps to reproduce

  1. Apply a recipe that installs display_builder/display_builder_page_layout and references the default profile, on Drupal 11.4 (tested 11.4.7-dev), without separately importing the optional config.
  2. Check display_builder.profile.default or /admin/config/content/formats: both are missing.

Workaround: explicitly config: import: both configs from the recipe.

Proposed resolution

  • Move both configs from config/optional to config/install so recipes get them too, or document the required config: import: workaround for recipe authors.

Remaining tasks

  • ✅ File an issue about this project
  • ✅ Addition/Change/Update/Fix to this project
  • ❌ Testing to ensure no regression
  • ✅ Automated unit/functional testing coverage
  • ➖ Developer Documentation support on feature change/addition
  • ❌ User Guide Documentation support on feature change/addition
  • ➖ UX/UI designer responsibilities
  • ➖ Accessibility and Readability
  • ❌ Reviewed by a human
  • ❌ Code review by maintainers
  • ❌ Full testing and approval
  • ❌ Credit contributors
  • ❌ Review with the product owner
  • ❌ Update Release Notes
  • ❌ Release

User interface changes

  • N/A

API changes

  • N/A

Data model changes

  • N/A

Release notes snippet

  • Fixed: recipes installing Display Builder no longer end up missing the default profile and text format.

AI-Generated: Yes

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

rajab natshah created an issue. See original summary.

rajab natshah’s picture

Issue summary: View changes

rajab natshah’s picture

Status: Active » Needs review

Should we manage with drupal:filter module or without it?

rajab natshah’s picture

Issue summary: View changes

Opened !397. Recipes install modules in syncing mode, so core skips the optional config and config entities.

A modules_installed hook now creates the missing default profile, and the text format when Filter is enabled, from the shipped YAML without overwriting existing config. Kernel tests cover a recipe install, a normal install and existing config being kept.

AI-Generated: Yes

mogtofu33’s picture

Status: Needs review » Needs work
Issue tags: +display_builder-1.0.0-beta8, +AI-accelerated

From my point of view, config management is the recipe's responsibility, and that is by design in core. RecipeRunner::installModules() installs modules in syncing mode, which skips every config entity a module ships, from config/install and config/optional alike. So moving these files to config/install would not change anything.

A recipe chooses what it takes from a module with config: import, by name like the core Standard recipe or with a wildcard like the core Example recipe.
Adding display_builder: '*' imports both the default profile and the text format. If a recipe does not import them, it is expected to provide its own.

Recreating this config in a modules_installed hook would also work against recipes that ship their own display_builder.profile.default. The hook creates it first, and the recipe's version is then skipped because it already exists.

What I think we should do instead:

  • Document the config: import line for recipe authors, and fix docs/textarea.md, which currently says the format is always created.
  • Replace the misleading "You are not allowed to use Display Builder" message when no profile exists with a clear hint and a link to create one.
rajab natshah’s picture

Status: Needs work » Closed (won't fix)

Got it,
Thanks, Jean.
After your comment, I see the point.
moving to change all my recipes to follow with the standard.

Seems like the better option.
Closing this issue as won't fix.
We can open it or file new issues when we want ..

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.