Layout Builder "Revert to defaults" confirmation form (and similar forms) do not nearly explain how destructive the operation is

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, 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?

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?

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:

All layout modifications and custom content blocks will be reset. Are you sure you want to continue?

Edit: What does happen to those inline blocks when you perform this operation?

After looking at #3528251: Layout Builder "Discard changes" confirmation form is destructive and does not communicate consequences to the user (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.

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!

We discussed this issue and #3528251: Layout Builder "Discard changes" confirmation form is destructive and does not communicate consequences to the user at #3532804: Drupal Usability Meeting 2025-07-04. 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.

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

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

I'll note that if the "Help" module is installed, the presumably helpful text "This layout builder tool allows you to configure the layout of the main content area. To manage other areas of the page, use the block administration page. Forms and links inside the content of the layout builder tool have been disabled." is embedded in this confirmation page, causing the important new text to be deemphasized:

This importance could be elevated by boldfacing the text, if desired. That being said, the language per the latest changes is accurate and grammatically correct, so I'm setting this to RTBC.

This looks good. Committed/pushed to 11.x, thanks!