Problem/Motivation

A front-end page can be built by up to three Display Builder layers: the page layout, the main content display (bundle display or override) and a Views page display.

The Navigation top bar exposes them in different places, with different labels, or not at all.
Users cannot tell what built the page they are looking at, or what a link will change.

Proposed resolution

One text-only "Display" item in the top bar, after core's page actions, listing every layer that built the current page with the scope of each. Core's "Edit" stays the only featured action.

No top bar inside the builders for now, so all builders behave the same. But something to decide and fix to avoid user navigation confusion.

Remaining tasks

Mockups

Mockup 1
Mockup 2
Mockup 3
Mockup 3

CommentFileSizeAuthor
#3 topbar_views.png297.38 KBmogtofu33
#3 topbar_node_override.png641.02 KBmogtofu33
#3 topbar_node_bundle.png573.28 KBmogtofu33
#3 topbar_homepage.png849.55 KBmogtofu33

Comments

mogtofu33 created an issue. See original summary.

mogtofu33’s picture

mogtofu33 commented
Assigned: Unassigned » pdureau
Status: Active » Needs review
mogtofu33’s picture

mogtofu33 commented
StatusFileSize
new topbar_homepage.png849.55 KB
new topbar_node_bundle.png573.28 KB
new topbar_node_override.png641.02 KB
new topbar_views.png297.38 KB
mogtofu33’s picture

mogtofu33 commented
Issue summary: View changes
pdureau’s picture

pdureau commented
Assigned: pdureau » mogtofu33
Status: Needs review » Active

I love the idea of extending #3616421: Add a navigation toolbar item in page built with Display builder to other displays.

the page layout, the main content display (bundle display or override) and a Views page display.

View page display is also embedded as the main content, so I guess the detection goes this way:

Can we reuse the logic from DisplayBuilderInterface::previewWithChrome()? It is also dealing with a display being the main content of a page, but maybe not, because it goes the opposite way.

mogtofu33’s picture

mogtofu33 commented
Assigned: mogtofu33 » Unassigned

I love the idea

Great, so I guess we agree on the plan, I propose to keep discussion here about the plan and mockup.

As I already created the child issues for each implementation (see on the right sidebar), would be way better to move discussion on each implementation on the corresponding issues, please put your View page display implementation in the corresponding issue.
I guess the reusable logic from DisplayBuilderInterface::previewWithChrome() is a good option and should be tested/done in the first issue of the plan which is yours: #3616421: Add a navigation toolbar item in page built with Display builder

mogtofu33’s picture

mogtofu33 commented
Issue summary: View changes
mogtofu33’s picture

mogtofu33 commented

Correcting myself on previewWithChrome(): as you guessed, it goes the opposite way. It answers "wrap this display's preview in chrome?" starting from the display, while the top bar needs "which displays built this request?" starting from the route. For page layouts, the only case in #3616421: Add a navigation toolbar item in page built with Display builder, it is a constant FALSE, so there is nothing to reuse there; loadCurrentPageLayout() already does the detection.

mogtofu33’s picture

mogtofu33 commented
Assigned: Unassigned » mogtofu33
Status: Active » Needs work