Add display-builder agnostic overview page for display modes

Hi,

Thanks for the issue and the proposal.

Would it ease flexibility and be future-proof that instead of "just" enable/disable on the view mode (and why not also form mode in the future :)), it should be a select list with the different display builders available:

- Disabled (empty value)
- Field UI
- Layout Builder
- Display Builder
- Canvas
- (other)

I have not checked but I guess then we could declare the display builder as plugins for discoverability, plugin methods/interface could provide the routes for local tasks, admin actions, etc. dynamically.

This looks like a good idea to me, haven't reviewed the MR yet.

We should open a follow-up to apply the same pattern to form modes, and also revive #2721727: Allow user to add display modes from respective field UI's. - that should allow removing the 'Display modes' menu item from admin/structure entirely, always forget that's where you have to go to add one.

Since view mode config entities have a description, could we put that in the table, and then make the help text less wordy?

Another thought I had about proposal from comment 5, is those "display_builder" plugins could implement a method to react to the change of selected display builder for view mode.

The method could have as arguments $previousBuilderId, $previousBuilderData. That way the plugins could optionally do data/config migration from one builder to it.

Would it be also the occasion to standardize "override per content" feature?

- Layout Builder allows to override the full view mode (or default if full is not enabled)
- Display Builder allows to override any view mode by allowing to select the field to store data into

@joachim Adding the description to the table sounds good, and yes good way to reduce the help text verbosity.

@grimreaper I think we should probably look at the display builder selection proposal in its own issue postponed on this one because it sounds like it might end up needing API changes/additions.

@catch I completely agree that it could be a big change and need to synchronize the change with the different display builder modules. So, to handle in its own issue at its own speed.

Child issue #3564677: Add a display_builder plugin API and selection created regarding comment 5, 8 and 9.

Does this need to go to usability review? Tagged for IS update for screenshot including added description.

Re: #14

I got a +1 from @ckrina in https://drupal.slack.com/archives/C079NQPQUEN/p1766215827620139 on this.

Awesome! I brought up usability review because I saw that the UX team had usability/accessibility concerns on #2409559: User should be able to identify required fields from field listing after it was already committed, so I thought maybe it'd be good to do that before committing here.

Hi,

Code review addressed from comment 15.

Ok for me.

Thanks and happy new year!

I didn't original think about an accessibility review of #2409559: User should be able to identify required fields from field listing because it was 'just a table', but when it was mentioned on that issue after commit, I realised it was adding some elements to combine information in a single table cell which probably could use accessibility review.

In this case though I think the new UI (at least from the screenshots) really is 'just a table' so it should not be introducing any new elements/patterns/styling that could introduce new accessibility issues. Haven't reviewed the actual MR here properly though.

Just want to say big +1 to this. I think this is a huge improvement.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Couple of questions on the MR.

Usability review

We discussed this issue at #3572725: Drupal Usability Meeting 2026-02-20. That issue has a link to a recording of the meeting.

The attendees at the usability meeting were @benjifisher, @pallavi singh3013, and @rkoller. I am giving them credit on this issue.

There are some things we like about the changes here:

• It is more consistent than the current approach, where the form for the Default view mode has an extra section (details element closed by default) that is not on the other forms.
• The extra section on the old Default form was a bit confusing, since a form should not manage unrelated features.

On the other hand, one drawback is that it will now require following an additional link when the user wants to edit the Default view mode.

I notice that there are a few more commits since we tested, and some of the problems we noticed are now fixed: the links on the overview page now have visually hidden text for improved accessibility, and they trigger a full page load so that the secondary tabs are updated.

There are three more things we do not like about the current state of this feature:

1. We miss the link ("Manage view modes") to /admin/structure/display-modes/view that used to be on the form for the Default view mode.
2. There is a lot of whitespace in the table, especially on large screens.
3. The tables on the Overview page are labeled "Enabled display modes" and "Disabled display modes". They should be "Enabled view modes" and "Disabled view modes".

It should be pretty easy to fix (1) by adding a sentence to the test at the top of the new Overview page.

A comprehensive fix for (2) is out of scope for this issue, so I opened #3574972: Admin tables can have too much horizontal whitespace, creating accessibility problems. For now, we could mitigate the problem by adding descriptions to the view modes in the Standard profile, and other core profiles. (That could be a follow-up issue.) Or we could simply remove the Description column from the tables on the Overview page.

Regarding (3), I know that I have trouble remembering which is which, but Display mode is the generic term, including View mode and Form mode. (This point did not come up during the usability meeting.)

One other thing we noticed is that there is no way to edit a disabled view mode. That is not a change from current behavior, so it is out of scope for this issue, but perhaps we should reconsider that behavior.

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

I found the sentence at the top a bit confusing, I think it works better just as 'Manage view modes' and moved it to the bottom which I felt is better suited to the priority of this task. (Specifically, the idea that you go there to 'edit' view modes is strange -- yes, you can change the name there, but the editing you probably want to do is here in the configuration of them.)

Not sure if I can RTBC this since I made a change but here's a screenshot of the updated UI in Gin:

That is definitely better :) I would drop the last sentence about enabling and disabling as needed, I think that’s self evident?

LGTM!

This MR is a beast and I haven't gotten all the way through yet, but since I found some things worth working on already and out of time for now, sending back to NW. I'll try to revisit soon and add any other comments.

Feedback is addressed, updated the screenshot in the IS for the current state.

I think this is in a good spot. Committed/pushed to main, thanks!

Is #2721727: Allow user to add display modes from respective field UI's. the right place to add an 'add' local action here, so that we can get closer to removing admin/structure/display-modes?

And do we need a follow-up to apply the same pattern to form modes?

Will need a backport MR for 11.x but looks like only one conflict in services.yml so hopefully not bad.

Actually had to do additional work for field_layout so putting in review for those changes.

Looks like needs more work

Lets try that.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Bad bot this rebased just fine with 11.x

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Actually looks like the field_layout changes still need review.

I couldn't figure out why PHPStan was complaining about FieldLayoutEntityDisplayFormTrait. It doesn't look like there are any related changes that would have made those return type declarations necessary. But maybe I missed something. I don't think they'll hurt anything, so they should be fine.

The most drastic change to be validated was to FunctionalJavascript/FieldLayoutTest. These changes were necessary because the test is dependent on the HTML structure of that page to test managing the layout. It had to be adapted to enable the required view mode in the newly designed display management page before accessing the view mode's settings. I manually followed the steps in the test and was able to verify that they're correct. The changes look good to me.

Committed/pushed to 11.x, thanks! I managed to mess up the attribution on the commit message - looks like issue credit didn't get saved last time. But issue credit should be correct as well as the commit on main.