Problem/Motivation
This issue is spun off from #3418179: [meta] Make config actions more dynamic.
In that issue, we identified several use cases that follow a similar pattern. Such as...
Adding the same permission(s) to all user roles:
user.role.*:
grantPermissions:
- 'access content'
Affecting the view display of every content type in the same way -- say, by removing a component you don't want people to see:
core.entity_view_display.node.*.*:
removeComponent: links
Changing settings on every instance of a field:
field.field.media.*.field_tags:
setSettings:
auto_create: false
Creating a view display (i.e., enabling a view mode) for every content type:
core.entity_view_display.node.*.foo:
ensure_exists:
# The contents of the view display here...
Overriding a base field for every media type:
core.base_field_override.media.*.thumbnail:
ensure_exists:
# The contents of the base field override here...
All of these uses have a similar need -- they have to be able to "select" the config items to change using * as a placeholder. Let's add that ability.
Proposed resolution
Right now, \Drupal\Core\Recipe\RecipeRunner::processConfiguration() very straightforwardly loops through every piece of config identified in a recipe's config:actions section.
Instead of taking each config name as given, we should run it through a transformation that first converts * to a regex (probably [a-z0-9_]+), then calls preg_grep() on the list of all config that exists in the active storage. Whatever comes out of that preg_grep() call is the actual list of config items that should have the action(s) applied.
User interface changes
None.
API changes
Yes, slightly new syntax for some use cases of recipes.
Issue fork distributions_recipes-3420209
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
Comment #3
phenaproximaAdded another use case to the issue summary.
Comment #5
narendrarComment #6
phenaproximaOh, I love the way this is looking!
I think w can harden it somewhat, and add more test coverage to be sure this really works as designed. :) Commented with some ideas.
Comment #7
phenaproximaComment #8
wim leersDid a detailed review and provided some pointers.
This relates to #3400672: Robustly validate the structure of recipe.yml, because this introduces a new way that would allow you to write invalid recipes.
Comment #9
narendrarThis MR still has phpstan issues, but wanted to make sure if this is heading in right direction.
Comment #10
wim leersReviewed 🏓 Definitely heading in the right direction!
Comment #11
wim leersStill needs more work — both @phenaproxima and I left remarks on what is missing/blocking RTBC.
Comment #12
phenaproximaHonestly, I'm not sure what else is needed here.
Comment #13
wim leersVery close! 👏 I see at least one missing test, one unnecessary method and one accidental public API addition, so for that.
Comment #14
phenaproximaI think it's ready for another look. All feedback resolved, except for one, which I'm not sure how to approach.
Comment #15
wim leersClose, but NW for
\Drupal\Core\Config\ConfigBase::validateName()and a test with a sample expression I provided that causes a PHP warning 🤓Comment #16
phenaproximaComment #17
wim leersAgreed we can question the wisdom of `ConfigBase::validateName()`, but that's not up to Recipes to change. Recipes should be able to install any config that is valid. So let's open a core issue to tighten that instead? :blush:
@chx requested in #1701014-63: Validate config object names to disallow
|and a range of other characters (but not(or)) and @xjm implemented it in #1701014-73: Validate config object names … but forgot|. So AFAICT the best course of action is to create a follow-up to tighten this in Drupal core 👍Comment #18
phenaproximaComment #21
alexpottCan someone file an issue against the documentation branch 1.x and add some docs from the issue summary about this. Thanks!
Comment #25
wim leers@phenaproxima or @narendraR, can you act on #21 + #17? 🙏
Comment #26
narendrarCreated https://www.drupal.org/project/drupal/issues/3424296 and https://www.drupal.org/project/distributions_recipes/issues/3424293
Comment #27
alexpottComment #28
wim leers