- Issue created by @mark_fullmer
- Merge request !12305Improve clarity of Layout Builder "Revert changes" confirmation form → (Open) created by mark_fullmer
- 🇳🇿New Zealand quietone
@mark_fullmer, thanks for the idea and the MR.
In Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → . Also mentioned on the version → section of the list of issue fields documentation.
- 🇳🇿New Zealand danielveza Brisbane, AU
Good idea! Put in a suggestion.
I think we should look at RevertOverridesForm too, that might be even more confusing than this one
- 🇮🇳India libbna New Delhi, India
Would it be appropriate to change the target branch of the existing merge request to 11.x (the default branch), or would you recommend creating a new branch from 11.x and applying the suggested changes there because I don't see any option to change the target branch?
Please advise on the preferred approach to proceed in line with current contribution practices.
- 🇺🇸United States mark_fullmer Tucson
In Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed
I've changed the target branch from 11.2.x to 11.x. Thanks!
- 🇺🇸United States mark_fullmer Tucson
I think we should look at RevertOverridesForm too, that might be even more confusing than this one
Agreed, although I'm not sure it's feasible to create a generic statement that accurately reflects what that action will do, given its variability based on site configuration. On one site, this might mean that the entity's Layout Builder sections will be reverted to a single, emtpy, one-column section. On others, "Revert layout" could restore the default sidebar content and order of the main content.
Given this, I think that issue should be dealt with separately.
- 🇳🇿New Zealand danielveza Brisbane, AU
Opened 📌 Improve clarity of Layout Builder "Revert to defaults" confirmation form Active for the revert form. Agree we should handle it seperately.
This is RTBC from me. I think its much better.
- 🇺🇸United States mark_fullmer Tucson
I'd offer some suggestions on the current proposed text, shown here:
This layout will be reverted to the default layout, any custom overrides will be lost. Are you sure you want to continue?
1. I'm not sure that for most content editors, the technical term "custom overrides" will be clear. Most content editors think of the changes they are making to a Layout Builder page as "adding content" or "modifying content." On top of this, it really depends on how Layout Builder is being used on a given site. If a Layout Builder entity view display is configured to display a bunch of fields from the entity, then what the content editor does with Layout Builder is a "modification" to the layout, or perhaps even an "override." If, however, the Layout Builder entity view display is more of a blank slate to which content editors add inline blocks of content, then content editors aren't going to think of this as a "modification/override" but as content additions.
2. From a grammatical perspective, a comma shouldn't be used to separate two independent clauses.Proposed revised language that tries to find the right balance between Drupal technical terminology and content editor comprehension:
This layout will be reverted to its default state. All layout and inline content will be reset. Are you sure you want to continue?