Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
Currently the recipe spec makes a recipe the authoritative source for all config.
There's indeed a use case for a recipe to cherry-pick particular config items as provided by an extension. But it's far from clear it's the most common use case--much less the only one.
Cherry-picking is a more complex approach, taking on a much higher level of responsibility; see discussion in #3283506: Document responsibility for required extension-provided configuration.
In some (possibly many or even most) cases, such as where a recipe author is also the author of modules the recipe installs, the recipe author presumably will want the module to perform as designed, including installing its full set of configuration.
This issue #3283827: Support multiple config update paths is related; a recipe author may wish to delegate authority for full updates as well as initial install to the extension.
Proposed resolution
install:
# An array of modules or themes to install, if they are not already.
# The system will detect if it is a theme or a module.
- event:
# Configuration is installed as usual when the extension is installed.
# Where available, configuration updates should include new config
# that's added to the module or theme.
config_provision: full
- easy_breadcrumb:
# During the install only simple configuration from the new modules is
# created. This allows the Drupal recipe control over the configuration.
# Where available, configuration updates should apply only to the
# config that was installed by the recipe.
config_provision: selective
- node:
# No configuration from the extension is installed or updated.
config_provision: none
- text:
config_provision: none
This covers #3283827 as well.
Remaining tasks
User interface changes
API changes
Data model changes
Issue fork distributions_recipes-3284701
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:
changes
Comments
Comment #2
nedjoComment #3
alexpottI think this is over complex and a solution was already discussed (at least I thought it was). I think we should allow wildcards in the list of config to install.
For example:
I really thought this was already in the doc... will create an MR to add this to the example.
Comment #4
nedjoLooks good to me!
An implementation detail we'll need to decide is:
(a) Does a wildcard trigger a regular full install for the module, bypassing the special case of a recipe-installed module where only simple config is installed? Or
(b) Does the recipe install the module as usual for a recipe and then collect all the module's
config/installandconfig/optionalconfig and install it?If it's (b), we have the problem that optional config calculation is embedded in
ConfigInstaller. That would bring the work in #2960888: Make config/install and config/optional methods reusable for config update use case into scope.Comment #5
alexpottCrediting @nedjo
Comment #8
alexpott