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.
| Comment | File | Size | Author |
|---|---|---|---|
| #36 | 3464550-nr-bot.txt | 90 bytes | needs-review-queue-bot |
Issue fork drupal-3464550
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:
- 3464550-10.4.x-tests
changes, plain diff MR !9877
- 3464550-create-config-action
changes, plain diff MR !8975
Comments
Comment #2
phenaproximaComment #3
phenaproximaStarshot is going to need this. Tagging as a blocker.
Comment #4
phenaproximaComment #6
quietone commentedShould be 11.x
Comment #7
a.dmitriiev commentedThis 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
createForEachNodeTypeand%bundleplaceholder 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!
Comment #8
damienmckennaComment #9
thejimbirch commentedA little premature for Needs review. I know @phenaproxima wants to work on this more.
Comment #10
phenaproximaThis has been a bit tricky but I think I can see a way to make it work, syntactically:
Comment #11
phenaproximaActually, I think I can refine that a bit. How about something like:
Comment #12
phenaproximaI'm happy with this and it has solid test coverage. It is, therefore, review o'clock.
Comment #13
phenaproximaComment #14
phenaproximaComment #15
thejimbirch commentedThis looks good to me. Would love to build a list of possible uses.
Going to mark it as RTBC so Alex takes a look.
Comment #16
phenaproximaAdjusting 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.Comment #17
phenaproximaComment #18
a.dmitriiev commented@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.
Comment #19
a.dmitriiev commentedI 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...
Comment #20
phenaproximaStraightforward feedback; self-assigning to address it.
Comment #21
phenaproximaComment #22
b_sharpe commentedRemoved 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
Comment #24
phenaproximaComment #25
alexpottBackported 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!
Comment #29
alexpottUnfortunately \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.
Comment #30
wim leersAre we not doing change records to announce the availability of this, and in which version it's available? 🤔
(Very cool BTW!)
Comment #31
thejimbirch commentedCommenting to add to the docs also.
Comment #32
phenaproximaSure - here's a change record explaining how this works. https://www.drupal.org/node/3481714
Comment #34
phenaproximaNeeds review for !9877, which is targeted to 10.4.x and has slightly different, but no less robust, test coverage.
Comment #35
b_sharpe commentedLooks good, test failure was unrelated and passing after rerun 👍
Comment #36
needs-review-queue-bot commentedThe 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.
Comment #37
phenaproximaComment #38
nod_yep sorry bot was on the wrong branch
Comment #39
alexpottCommitted 2013eb8 and pushed to 10.4.x. Thanks!
Comment #42
thejimbirch commented