Problem/Motivation
When new view mode is enabled for the content type, for example, with UI, new view display always is copied from the "Default" display, meaning all the fields that are used in default display are added to the newly enabled display with the same settings. Later the new display can be adjusted to the needs.
Steps to reproduce
When the new view mode is enabled for the content type with recipes, no fields (components) are added to it by default. One needs explicitly provide the components with names and there settings. But sometimes, the names and settings are unknown in advance, and to be flexible and dynamic, it would be nice to have the config action that would copy the default view display, but for another view mode.
I believe there would be a lot of other use cases, for example, creating the config splits for lower environments, as they can be the same with only slight differences, etc.
Proposed resolution
Create config action that will duplicate config entity. For example:
core.entity_view_display.node.page.default:
cloneAs: node.page.search_result
The config entity that is duplicated of course should be of the same type as the given config. This should be validated in the config action.
Release notes snippet
New config action to duplicate config entity. Recipe example usage:
core.entity_view_display.node.page.default:
cloneAs: node.page.search_result
Issue fork drupal-3481238
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:
- 3481238-config-action-to
changes, plain diff MR !9854
Comments
Comment #2
phenaproximaThis seems like a reasonable and useful feature, so +1.
I'm not sure that
duplicateIfNotExistsmakes sense, though; by definition, you can't duplicate a thing if the duplicate already exists.I would suggest we make this as simple as possible, where the action only takes a string, which is the ID of the duplicate to create. So:
In other words, this action should only be able to work on config entities that already exist.
Comment #3
phenaproximaAlso, I know this feature will be needed for Drupal CMS, so tagging as a Starshot blocker.
Comment #4
a.dmitriiev commentedAgree with #2.
Comment #5
phenaproximaComment #7
phenaproximaComment #8
phenaproximaComment #9
b_sharpe commentedUp for discussion, but if I'm wanting to clone an existing config and it doesn't exist, I'd expect an error here rather than just not cloning as this could affect further actions.
Comment #10
phenaproximaI think I agree with you, on second thought. Adjusted!
Comment #11
b_sharpe commentedNice! Tested and working as designed. RTBC
Comment #12
alexpottCommitted and pushed 520019bb2fe to 11.x and 36a124b2f5e to 10.4.x. Thanks!
Fixed on commit.
Comment #16
wim leersAre we not doing change records to announce the availability of this, and in which version it's available? 🤔
(Very cool BTW!)
Comment #17
thejimbirch commentedNeeds to be added to the docs also.
Comment #18
phenaproximaChange record written: https://www.drupal.org/node/3481718
Comment #20
thejimbirch commented