Content editors using Layout Builder's "Discard changes" button may not be clear what this action does, in comparison to the "Revert layout" button adjacent to it. Both actions include a confirmation step, but the confirmation text does not provide much clarification. For "Discard changes," the text reads "Are you sure you want to discard your layout changes?" while "Revert defaults" reads simply "Are you sure you want to revert this to defaults?"
1. Use the "Discard changes" button in the Layout Builder interface.
2. See the text of the confirmation dialog.
3. Scratch your head in perplexity.
Update the text to read "Any changes made since the last saved layout will be removed. Are you sure you want to discard your layout changes?"
None.
Textual only.
None.
None.
None.
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | Screenshot from 2025-07-04 09-12-04.png | 51.8 KB | danielveza |
| #17 | Screenshot from 2025-07-04 09-09-35.png | 54.85 KB | danielveza |
| #17 | Screenshot from 2025-07-04 09-06-32.png | 48.11 KB | danielveza |
Show commandsStart 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:
changes, plain diff MR !12305
Comments
Comment #3
mark_fullmerComment #4
quietone commented@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.
Comment #5
danielvezaGood idea! Put in a suggestion.
I think we should look at RevertOverridesForm too, that might be even more confusing than this one
Comment #6
libbna commentedWould 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.
Comment #7
mark_fullmerI've changed the target branch from 11.2.x to 11.x. Thanks!
Comment #8
mark_fullmerComment #9
mark_fullmerAgreed, 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.
Comment #10
danielvezaOpened #3528494: Layout Builder "Revert to defaults" confirmation form (and similar forms) do not nearly explain how destructive the operation is for the revert form. Agree we should handle it seperately.
This is RTBC from me. I think its much better.
Comment #11
libbna commentedComment #12
mark_fullmerText redacted -- wrong issue!
Comment #13
mark_fullmerComment #14
xjmSo #3528494: Layout Builder "Revert to defaults" confirmation form (and similar forms) do not nearly explain how destructive the operation is is alluding to what's happening to inline blocks under that operation. This one doesn't.
I'm not sure these issues should be handled separately; in fact; I think we should handle them together. I've asked for the other to be closed dupe and merged back here so we can discuss the language and the user experience for these two operations together, since we need to inform the user what's going to happen to their stuff as a result (including inline blocks, as the other issue points out). If we handle them separately, we'll end up with two different streams of discussion about what information to include and the how to compare the two operations.
Comment #15
xjmPostponing on the other issue, and tagging for UX manager review.
Comment #16
xjmRescoping as bug, like the other issue.
Comment #17
danielvezaHmm. Prepping screenshots for this I don't think the approach taken in the code is correct.
This is how the form looks on 11.x
After applying the MR
This is wrong to me, when I reviewed it I thought the description text was updated. I think we should leave the question as it is in 11.x and update the description text instead by overriding ::getDescription with the text based on the decision of the UX team
Doing it on my local looks like this.
Comment #18
xjmPer #3528494-22: Layout Builder "Revert to defaults" confirmation form (and similar forms) do not nearly explain how destructive the operation is this should be added to the scope of the other issue.
We have all the same creditable participants, so no credits to transfer. Thanks everyone!