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.

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

phenaproxima created an issue. See original summary.

narendraR made their first commit to this issue’s fork.

phenaproxima’s picture

Issue summary: View changes

Added another use case to the issue summary.

narendrar’s picture

Status: Active » Needs review
phenaproxima’s picture

Status: Needs review » Needs work

Oh, 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.

phenaproxima’s picture

Title: Allow config actions to be applied to all config items whose names match a particular pattern » Allow config actions to be applied to multiple config entities using wildcards
wim leers’s picture

Did 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.

narendrar’s picture

Status: Needs work » Needs review

This MR still has phpstan issues, but wanted to make sure if this is heading in right direction.

wim leers’s picture

Status: Needs review » Needs work

Reviewed 🏓 Definitely heading in the right direction!

wim leers’s picture

Still needs more work — both @phenaproxima and I left remarks on what is missing/blocking RTBC.

phenaproxima’s picture

Status: Needs work » Needs review

Honestly, I'm not sure what else is needed here.

wim leers’s picture

Status: Needs review » Needs work

Very close! 👏 I see at least one missing test, one unnecessary method and one accidental public API addition, so Needs work for that.

phenaproxima’s picture

Status: Needs work » Needs review

I think it's ready for another look. All feedback resolved, except for one, which I'm not sure how to approach.

wim leers’s picture

Close, but NW for \Drupal\Core\Config\ConfigBase::validateName() and a test with a sample expression I provided that causes a PHP warning 🤓

phenaproxima’s picture

Status: Needs work » Needs review
wim leers’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: +Needs followup

Agreed 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 👍

phenaproxima’s picture

Issue summary: View changes

alexpott made their first commit to this issue’s fork.

  • alexpott committed 0954af94 on 11.x authored by narendraR
    Issue #3420209 by phenaproxima, narendraR, Wim Leers: Allow config...
alexpott’s picture

Version: 11.x-dev » 10.2.x-dev
Status: Reviewed & tested by the community » Fixed

Can someone file an issue against the documentation branch 1.x and add some docs from the issue summary about this. Thanks!

  • alexpott committed bc2542b5 on 10.2.x authored by narendraR
    Issue #3420209 by phenaproxima, narendraR, Wim Leers: Allow config...

  • 49287cc9 committed on patch
    Update recipe 11.x patch 0954af94 Issue #3420209 by phenaproxima,...

  • 536bec39 committed on patch
    Update recipe 10.2.x patch bc2542b5 Issue #3420209 by phenaproxima,...
wim leers’s picture

Status: Fixed » Patch (to be ported)

@phenaproxima or @narendraR, can you act on #21 + #17? 🙏

narendrar’s picture

alexpott’s picture

Status: Patch (to be ported) » Fixed
wim leers’s picture

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.