Problem/Motivation

The addToAllBundles action supported by fields is very, very useful. But it really would be even better if it worked on all config entity types that target a particular bundle.

For example, if I want to add the same set of meta tags to every content type...there's no way to do that dynamically without Metatag adding a custom config action for it. Simple Sitemap works the same way. Another example is making a content type translatable; you need to add a config entity for each bundle to hold the translation settings.

It's a pretty common pattern, but the recipe system has no real support for it.

Proposed resolution

Create a pair of generic actions called createForEach and createForEachIfNotExists. These actions are meant to be used with wildcards, and can only work on entities that are bundles of another entity type, such as node types, media types, taxonomy terms, and so forth.

The syntax works kind of like a meta-create:

node.type.*:
  createForEach:
    image.style.node_%bundle_big:
      label: 'Big %label content image'
    language.content_settings.node.%bundle:
      target_entity_type_id: node
      target_bundle: %bundle

The %bundle placeholder is replaced with the ID of the bundle entity being processed, which is the same syntax as the grantPermissionsForEachNodeType action. This also supports a %label placeholder (in the array values only, not the keys) which is replaced with the bundle's human-readable label.

CommentFileSizeAuthor
#36 3464550-nr-bot.txt90 bytesneeds-review-queue-bot

Issue fork drupal-3464550

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.

phenaproxima’s picture

Issue summary: View changes
phenaproxima’s picture

Issue tags: +Starshot blocker

Starshot is going to need this. Tagging as a blocker.

phenaproxima’s picture

Issue summary: View changes

quietone’s picture

Version: 11.0.x-dev » 11.x-dev

Should be 11.x

a.dmitriiev’s picture

This is very helpful and needed config action.

For my use case, the module provides a new form mode that should be added to all node types, as this form mode is used for a new route that the module provides. It has to be added to all bundles.

With help of config action createForEachNodeType and %bundle placeholder I was able to accomplish this task while testing MR.

I am not yet changing the status of the issue, but with current state of MR it is possible to create config entities for each bundle of entity type.

Thank you for a handy feature!

damienmckenna’s picture

Status: Active » Needs review
thejimbirch’s picture

Status: Needs review » Active

A little premature for Needs review. I know @phenaproxima wants to work on this more.

phenaproxima’s picture

Assigned: Unassigned » phenaproxima

This has been a bit tricky but I think I can see a way to make it work, syntactically:

node.type.*:
  createEachOf:  # There will also be createEachOfIfNotExists
    language_content_settings:  # The entity type ID to create
      # An array of values for the language_content_settings entity, where `%bundle` is replaced with the ID of the node type. We can automatically detect this because this action will only work on config entities that are bundles of another entity type.
    media_type:  # Create a media type for each node type
      # An array of values for the media_type entity, with the `%bundle` replacement
phenaproxima’s picture

Actually, I think I can refine that a bit. How about something like:

config:
    actions:
        node.type.*:
            createForEach: # Or createForEachIfNotExists
                image.style.%bundle_big:
                  # some values for the image style
                language.content_settings.node.%bundle:
                  # some values for the language settings
phenaproxima’s picture

Assigned: phenaproxima » Unassigned
Status: Active » Needs review

I'm happy with this and it has solid test coverage. It is, therefore, review o'clock.

phenaproxima’s picture

Issue summary: View changes
phenaproxima’s picture

Issue summary: View changes
thejimbirch’s picture

Status: Needs review » Reviewed & tested by the community

This looks good to me. Would love to build a list of possible uses.

Going to mark it as RTBC so Alex takes a look.

phenaproxima’s picture

Issue summary: View changes

Adjusting the issue summary to account for a bug fix I'm doing in EntityCreate as part of this -- it should not assume that the ID property of a config entity is id.

phenaproxima’s picture

Issue summary: View changes
a.dmitriiev’s picture

@thejimbirch you can add the following to the list of uses:

Search Track needs this feature to enable search_index and search_results view modes for all node type that exist in the system. The recipe imports the view modes from node core module and then needs to create view displays for all node types, so that it is possible to configure what information will be indexed and how the search result will look like.

Here is the issue https://www.drupal.org/project/drupal_cms/issues/3468271 . For MR I was using the old patch, that was removed (I restored it in the MR, because the functionality is needed, but now can be substituted with this new approach).

I will also try to try the latest change from this issue and how it can be applied to my use case.

a.dmitriiev’s picture

I can confirm that this approach is working, I have added the patch to corresponding Drupal CMS issue https://www.drupal.org/project/drupal_cms/issues/3467212#comment-15817015 . The usage can be found here https://git.drupalcode.org/project/drupal_cms/-/merge_requests/127/diffs...

phenaproxima’s picture

Assigned: Unassigned » phenaproxima
Status: Reviewed & tested by the community » Needs work

Straightforward feedback; self-assigning to address it.

phenaproxima’s picture

Assigned: phenaproxima » Unassigned
Status: Needs work » Needs review
b_sharpe’s picture

Status: Needs review » Reviewed & tested by the community

Removed my comment as I think base plugins make sense to be named this way as in `entity_create` and have derivatives be camel case. Everything looks great! RTBC

phenaproxima’s picture

alexpott’s picture

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

Backported to 10.4.x to keep 10 and 11 recipes the same when 10.4.0 and 11.1.0 come out.

Committed and pushed b03d9ab8014 to 11.x and fcbad7f5bda to 10.4.x. Thanks!

  • alexpott committed fcbad7f5 on 10.4.x
    Issue #3464550 by phenaproxima, a.dmitriiev, b_sharpe, alexpott: Create...

  • alexpott committed b03d9ab8 on 11.x
    Issue #3464550 by phenaproxima, a.dmitriiev, b_sharpe, alexpott: Create...

  • alexpott committed b7eee72c on 10.4.x
    Revert "Issue #3464550 by phenaproxima, a.dmitriiev, b_sharpe, alexpott...
alexpott’s picture

Version: 10.4.x-dev » 11.x-dev

Unfortunately \Drupal\KernelTests\Core\Recipe\WildcardConfigActionsTest::testCreateForEachValidatesCreatedEntities() fails on 10.4.x because the config schema validation for imsage styles is not in the 10.4.x branch. Not sure how to fix this... I'd like it if recipes in 10.4.0 and 11.1.0 has the same capabilities - maybe we just need to drop this test.

wim leers’s picture

Issue tags: +Needs change record

Are we not doing change records to announce the availability of this, and in which version it's available? 🤔

(Very cool BTW!)

thejimbirch’s picture

Commenting to add to the docs also.

phenaproxima’s picture

Issue tags: -Needs change record

Sure - here's a change record explaining how this works. https://www.drupal.org/node/3481714

phenaproxima’s picture

Status: Fixed » Needs review

Needs review for !9877, which is targeted to 10.4.x and has slightly different, but no less robust, test coverage.

b_sharpe’s picture

Status: Needs review » Reviewed & tested by the community

Looks good, test failure was unrelated and passing after rerun 👍

needs-review-queue-bot’s picture

Status: Reviewed & tested by the community » Needs work
StatusFileSize
new90 bytes

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

phenaproxima’s picture

Status: Needs work » Reviewed & tested by the community
nod_’s picture

yep sorry bot was on the wrong branch

alexpott’s picture

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

Committed 2013eb8 and pushed to 10.4.x. Thanks!

  • alexpott committed 2013eb87 on 10.4.x
    Issue #3464550 by phenaproxima, a.dmitriiev, alexpott, b_sharpe: Create...

Status: Fixed » Closed (fixed)

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

thejimbirch’s picture