Closed (won't fix)
Project:
Display Builder
Version:
1.0.0-beta7
Component:
Main / Misc.
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
12 Sep 2026 at 12:52 UTC
Updated:
15 Sep 2026 at 16:14 UTC
Jump to comment: Most recent
Comments
Comment #2
rajab natshahComment #4
rajab natshahShould we manage with
drupal:filtermodule or without it?Comment #5
rajab natshahOpened !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
Comment #6
mogtofu33 commentedFrom 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:
Comment #7
rajab natshahGot 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 ..