Create config action which can create an entity for every bundle of another entity type

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

Should be 11.x

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!

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

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

node.type.*:
  createForEach:  # There will also be createIfNotExistsForEach
    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

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

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

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.

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.

@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 📌 Add recipe for search backend Active . 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.

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 📌 [IGNORE] Patch storage issue Active . The usage can be found here https://git.drupalcode.org/project/drupal_cms/-/merge_requests/127/diffs...

Straightforward feedback; self-assigning to address it.

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 → credited alexpott → .

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!

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.

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

(Very cool BTW!)

Commenting to add to the docs also.

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

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

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

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.

yep sorry bot was on the wrong branch

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

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