Problem/Motivation
When we did #3562060: Render UI with admin theme , it was decided to not hide the "Default Admin" theme toolbar on display builder pages because there was uncertainties about how this toolbar is added and we didn't want to risk side effects by using a loosely defined hook.
I guess it was the good approach at this time, but we have now something kind of useless which is taking as much screen estate as our toolbar:

Proposed resolution
2 weeks after the switch to admin theme, we can try again as an isolated task.
Test with Claro, Gin contrib and the new default admin theme.
Let's keep the "do we need still need the Expand button?" question out of this discussion. It is tempting to ask such question once the Gin toolbar is removed. But it was discussed many times since July and it was confirmed as absolutely needed, even before this Gin toolbar was visible, even if I personally still struggle to understand this.
Issue fork display_builder-3633034
Show commands
Start 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:
Comments
Comment #3
pdureau commenteddefault_adminhas no top bar of its own: it re-themes the one core Navigation builds. So we need to addressMR ready for review: https://git.drupalcode.org/project/display_builder/-/merge_reque
I was not able to just copy what we already got in #3562060: Render UI with admin theme because it triggers a PHPMD NPathComplexity errror.
All tests with Drupal 11.4 and the navigation nodule installed.
/admin/structure/page-layoutwith the expected breadcrumb and local actions/user/1with the expected title and buttonsI keep on my side because of a phpunit functional error on
OverrideDisplayTabsTest:Checked with
/node/2/display/defaultwhich is the node entity equivalent of the test. It is weird because this links doesn't exist in those pages, with or without the current change.Comment #4
pdureau commentedI have added a check related to current theme:
All tests with Drupal 11.4 and the navigation nodule installed:
/admin/structure/page-layoutwith the expected breadcrumb and local actions/user/1with the expected title and buttonsComment #5
smovs commentedHi team!
Tested MR !514 on Drupal 11.4.11 with Navigation, UI Skins 1.2.1 and Gin 5.0.16.
/admin/structure/page-layout/user/1Gin's
top-bar--gin.html.twigis the same as Default Admin's top bar, butisTopBarTheme()only checksdefault_admin. Making it also matchginhides the top bar on the builder page under Gin and keeps it on the other pages.The MR's new test (
ThemeHooksChromeTest) passes.OverrideDisplayTabsTest, reported as failing in #3, passes for me with and without the MR, so the MR doesn't break it.Comment #6
pdureau commentedThanks Sviatoslav for testing with Gin. It was out of the scope of my review, but it is relevant. Can you propose a fix?
Comment #7
smovs commentedInstead of adding Gin to the theme check, I'd suggest basing the decision on the top bar's template rather than on the theme's name.
Core Navigation's own top bar renders nothing on builder pages, which is why Claro shows nothing there. The bar only gets in the way when something replaces its template with one that always renders and repeats the breadcrumbs, tabs and actions the builder toolbar already shows. Default Admin and Gin do this with a theme suggestion. A module can do it too: Gin Toolbar overrides the template, so even Claro shows Gin's full top bar.
So the rule could be: on builder pages, hide the top bar only when its template has been replaced by a theme or a module. The active theme's registry tells us that, so there's no list of themes to maintain. Unknown admin themes and modules are handled automatically. Core's own top bar stays, as intended in #4, the navigation sidebar is always kept, and other pages are unaffected.
Other options I considered:
One trade-off: the replaced top bars also hold the mobile "Expand sidebar" button, so it would be gone from builder pages. The MR already accepts this for Default Admin.
If this direction sounds good, I can update the MR.
Comment #8
pdureau commented🤔 I am hesitating:
🤔 That's why we want to do in the scope of this ticket. Maybe the proposal of comment #3 was already the good one, and it would be better to fix the test than add a condition about theme, like what has been done in #4.
❌ Already a separated issue: #3529095: Adopt navigation module's top bar, which has been postponed partially because Navigation Toolbar was initially designed to be displayed in front theme pages only. However, because Default Admin (and Gin) is now using it for admin pages, it may be relevant again.
It will not be easier though, because instead of hiding the toolbar on Display Builder pages, we will need to remove the
ToolbarItemplugins which are not ours.❌ No settings. Just sensible default behaviour.
❌ Too fragile indeed.
Comment #9
csakiistvanComment #10
csakiistvan❌ Does not fix the issue — applied MR !514 on top of current 1.0.x with Navigation enabled, rebuilt caches and opened a page layout builder: under Default Admin the top bar is gone from the builder page and still shown on /admin/structure/page-layout, but with Gin as admin theme the top bar is still rendered above the builder toolbar. Gin, listed in the proposed resolution, is not covered yet (same as #7).
Prerequisites
navigation, installdefault_admin; switch the admin theme withdrush config:set system.theme admin gin./admin/structure/page-layout/{id}/builder.Code review
7a4353a5, rebased on 1.0.x, pipeline green.isTopBarTheme()only matchesdefault_adminand its sub-themes; Gin (base theme Claro) ships its own top bar template, so it never matches.Comment #11
csakiistvanWent with the approach from #3: the top bar is now removed on every builder page, whatever the admin theme. No theme list to maintain, and the behaviour is the same everywhere.
Side effect: the "Display: …" links from core Navigation's top bar are gone from entity view builder pages. Restoring them belongs to #3529095: Adopt navigation module's top bar.
Tests are updated and pass. Please test with Navigation enabled under Default Admin, Claro and Gin: the builder page should have no top bar, while
/admin/structure/page-layoutand/user/1keep it.Comment #12
smovs commentedHi @csakiistvan! Thanks for the update.
Tested the latest commit of MR !514 (148bdae) on Drupal 11.4.11 with Navigation, Gin 5.0.16 and Gin Toolbar 3.0.3.
The navigation sidebar is kept on every page.
For comparison, on the previous commit (7a4353a) the top bar was still shown on the builder page under Claro and Gin. Claro shows it there because Gin Toolbar overrides the top bar template, as mentioned in #7. With 148bdae it is gone under all three themes.
The trade-off I raised in #7 doesn't apply: the mobile "Expand sidebar" button is still on the builder page under Default Admin and Gin. It lives in Navigation's control bar, not in the top bar.
ThemeHooksChromeTestandOverrideDisplayTabsTestpass locally.Losing the "Display: …" links on entity view builder pages is expected and covered by the updated test. Restoring them belongs to #3529095: Adopt navigation module's top bar.
Moving to RTBC.
Comment #13
andres alvarez commentedI tested commit
148bdaeof MR !514 on cases the previous comments did not cover: Claro as the admin theme, mobile, and a site without Navigation. All on Drupal 11.4.6 with Firefox, on throwaway test sites. Before and after compare against 1.0.x (654df5a)./node/1/display/full): with the MR the top bar is gone and the sidebar stays. On 1.0.x the bar showed (title, Published, Edit and the Display menu). Screenshots 1 and 2./user/1and/node/1: the bar is kept, as expected.ThemeHooksChromeTestandOverrideDisplayTabsTestpass locally.One observation, not blocking the RTBC: under Claro, on the entity override builder the Edit button, the ⋮ menu and the "Display" dropdown also disappear, so the link back to the entity is gone. I understand that is the intended effect and that restoring it depends on #3529095.
Not tested: Gin, Default Admin, Drupal 11.4.11 or other browsers (already covered by @smovs in #12).
Comment #15
mogtofu33 commentedThanks for the work here.