Improve clarity of Layout Builder "Revert to defaults" confirmation form

I have replaced the revert confirmation text Are you sure you want to revert this to defaults? with This layout will be reverted to the default layout, any custom overrides will be lost. Are you sure you want to continue?. However, in my opinion, this message may be a bit too long. As noted in one of the comments on https://www.drupal.org/project/drupal/issues/3528251 ✨ Improve clarity of Layout Builder "Revert changes" confirmation form Active , and to maintain consistency, could we consider using the existing message Any unsaved changes to the layout will be lost. This action cannot be undone. instead?

could we consider using the existing message Any unsaved changes to the layout will be lost. This action cannot be undone. instead?

In the Revert form, this message wouldn't be accurate. Changes to the layout have already been saved.

Reverting to default is more desctructive (but can be restored by reverting to a past revision) than discarding changes (Which is just clearning the tempstore), so I think a more verbose message makes sense here.

Understood, thanks @danielveza for the clarification. I'm unassigning myself for now—if any further changes are needed, I'm happy to jump back in.

Seems like a good simple update

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 modifications and inline content will be reset. Are you sure you want to continue?

+1 to the suggestion from @mark_fullmer.

Adding the novice tag since this should be a good first issue for an new contributor. If its not picked up by a novice or @libbna in a week or so I'll jump in and do it

I have updated the text as suggested by @mark_fullmer. Changing the status to needs review.

Thanks for making that change. LGTM.

This is a great improvement! The operation is indeed pretty destructive.

One quibble, though: As written, "inline content" sounds worse than it is. That sounds like... all your content, rather than just potentially a whole bunch of content.

Do we not use the term "inline blocks" in the user interface?

The action to make them in the UI is "create content block" so let's use that language.

After looking at ✨ Improve clarity of Layout Builder "Revert changes" confirmation form Active (which I missed at first), I think we need to discuss both in the same issue. This should be merged back there and then closed as a duplicate.

I think the existing text for this particular form is pretty terrible , I'd recommend we merge this so it can at least be improved without being stalled on discussions about the particular language tweaks.

The points raised in #16 are 100% valid, but my 2c would be to improve this now. The discussions can and should still continue in the other issue, but I don't want the text for this one to stay in it's current state if the other issue takes awhile to get in.

Thanks @danielveza! I agree that this is a serious issue. In fact, I'm bumping this to major and changing it to bug. Retitling as such

Please keep in mind that regardless of what is committed when, both these improvements are string changes, and as such will only be committed to 11.x according to our allowed changes policy for frontend bug fixes → . As such, the fixes will only be available in 11.3.0, which is released in December. I'm confident we can get both these issues fixed by then, whether we handle them together or separately!

As a release manager, I make recommendations about issue scoping so that we manage our changes in the best way we can.

In this case, these two usability problems are similar, and the users need to understand the two different operations. That's why I think we need to discuss them together, and have an usability review of our changes according to the core usability gate → . I'm not tagging for usability review yet because we would need screenshots and such.

I'm also going to seek the input of our UX managers since what we do here is ultimately under their guidance. Thanks everyone!

Similar to ✨ Improve clarity of Layout Builder "Revert changes" confirmation form Active , while prepping screenshots for this I don't think the approach currently taken in the code is correct. I was thinking that the description of the text had been updated, but it's actually the title. Attaching some screenshots of the form before/after applying the current MR, and a screenshot of an example of how it could look with overriding ::getDescription as well.

Current form in 11.x:

After applying MR:

Screenshot from my local, moving some of the text into the description (The title question still feels too long here):

I've attached screenshots of this and ✨ Improve clarity of Layout Builder "Revert changes" confirmation form Active with some suggestions of how it currently looks and how it should potentially look, so it can be reviewed by the UX team and a choice on the question & description can be made for both the question & the description of both issues.

We discussed this issue and ✨ Improve clarity of Layout Builder "Revert changes" confirmation form Active at 📌 Drupal Usability Meeting 2025-07-04 Active . That issue will have a link to a recording of the meeting. For the record, the attendees at today's usability meeting were @benjifisher, @rkoller, and @simohell.

We agree with Comment #16: this issue should be combined with #3528251. @danielveza, your own Comment #20 suggests that the current MR for this issue is not a good solution (and we agree). That seems at odds with your reasons in Comment #17 for not combining the issues.

We did a little testing, and we can confirm that inline blocks (Content blocks created in Layout Builder) are deleted from the database if you Discard changes. If you have inline blocks saved in a custom layout, and you Revert to defaults, then they are still in the database but you cannot use them nor even edit them. (The page at `/admin/content/block` is a View. By default, it filters on Reusable: True. It is easy to edit that view and expose that filter, and then you can list the inline blocks.)

We did not settle on recommended text for these forms, but we can suggest some guidelines:

1. Use the description text instead of a long title. (We agree with Comment #20.)
2. Do not repeat things in the title and the description (as pointed out in Comment #20).
3. Shorten the existing title. Make it a statement, not a question, consistent with the choices Confirm/Cancel. We would like something like "Revert to the default layout".
4. Give context about which page is affected. Think of the content editor who gets interrupted, or is editing the layout of several pages in different tabs.

We also noticed a few problems that are not in the scope of this issue. The Umami demo profile does not display the confirmation form well. It would be nice to implement #1842036: [META] Convert all confirm forms to use modal dialog → .

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

xjm → credited rkoller → .

xjm → credited simohell → .

Thanks @danielveza and @benjifisher. Adding credits from the Usability meeting.

Updating the IS to clarfiy new scope for this issue

Taken a stab at implemented the suggestions from #22. Both forms are now being updated. Changes pushed & tests are green. Adding some screenshots of the new text and how it looks on the form. As per the suggestion in #22, I've also included the label of the entity (where possible), falling back to a more generic message if no entity context is available (Like when editing a default layout).

The meanings of these two actions are much clearer with the updated form texts, thanks! Posted a couple small suggestions.