Show the admin bar in the Post and Site Editor by default by fushar · Pull Request #79197 · WordPress/gutenberg

fushar · 2026-06-15T15:06:15Z

Also fixes #57813

What?

This PR shows the admin bar in the Post and Site Editor by default, hiding it ONLY when:

In Post Editor, when the Fullscreen mode and Distraction-free mode are BOTH turned on.
In Site Editor, when the Distraction-free mode is turned on (Fullscreen mode can't be disabled here).

Now that the admin bar is back which identifies the site context, this PR replaces the now-redundant top-left W/site icon with an explicit back button, resulting in a more obvious navigation control.

Why?

This is part of an effort to make navigation across wp-admin screens more consistent. See: #79083

How?

This essentially "graduates" that part of the feature from the following experiment, moving the logic out of the experiment gating.

Add experiment to show admin bar in Post and Site Editor #77964

Testing Instructions

Test the following scenarios depicted by the following screenshots.

Screenshots or screencast

Post Editor

Before	After
Navigation	Navigation
Fullscreen ON, Distraction-free off	Fullscreen ON, Distraction-free off
Fullscreen ON, Distraction-free ON	Fullscreen ON, Distraction-free ON (NO CHANGE)
Fullscreen off, Distraction-free off	Fullscreen off, Distraction-free off (NO CHANGE)
Fullscreen off, Distraction-free ON	Fullscreen off, Distraction-free ON (NO CHANGE)

Site Editor

Before	After
Navigation	Navigation
Navigation	Navigation
Distraction-free off	Distraction-free off
Distraction-free ON	Distraction-free ON (NO CHANGE)

Site Editor V2

(Enable the Extensible Site Editor experiment, then visit Appearance -> Site Editor)

Before	After

Use of AI Tools

I used Claude Code with Opus 4.8 to help migrate the logic out from the experiment gating.

github-actions · 2026-06-17T07:46:15Z

Size Change: -13.4 kB (-0.18%)

Total Size: 7.49 MB

📦 View Changed

Filename	Size	Change
`build/modules/boot/index.min.js`	50.8 kB	-2.08 kB (-3.92%)
`build/scripts/edit-post/index.min.js`	51.8 kB	-1.13 kB (-2.14%)
`build/scripts/edit-site/index.min.js`	297 kB	-1.54 kB (-0.52%)
`build/scripts/editor/index.min.js`	473 kB	-48 B (-0.01%)
`build/styles/edit-post/experimental-omnibar-rtl.css`	0 B	-550 B (removed)	🏆
`build/styles/edit-post/experimental-omnibar-rtl.min.css`	0 B	-516 B (removed)	🏆
`build/styles/edit-post/experimental-omnibar.css`	0 B	-551 B (removed)	🏆
`build/styles/edit-post/experimental-omnibar.min.css`	0 B	-517 B (removed)	🏆
`build/styles/edit-post/style-rtl.css`	3.48 kB	-352 B (-9.2%)	✅
`build/styles/edit-post/style-rtl.min.css`	2.21 kB	-307 B (-12.22%)	👏
`build/styles/edit-post/style.css`	3.48 kB	-351 B (-9.16%)	✅
`build/styles/edit-post/style.min.css`	2.21 kB	-309 B (-12.27%)	👏
`build/styles/edit-site/experimental-omnibar-rtl.css`	0 B	-898 B (removed)	🏆
`build/styles/edit-site/experimental-omnibar-rtl.min.css`	0 B	-492 B (removed)	🏆
`build/styles/edit-site/experimental-omnibar.css`	0 B	-898 B (removed)	🏆
`build/styles/edit-site/experimental-omnibar.min.css`	0 B	-492 B (removed)	🏆
`build/styles/edit-site/style-rtl.css`	21.5 kB	-561 B (-2.54%)
`build/styles/edit-site/style-rtl.min.css`	17.7 kB	-514 B (-2.82%)
`build/styles/edit-site/style.css`	21.5 kB	-567 B (-2.56%)
`build/styles/edit-site/style.min.css`	17.7 kB	-519 B (-2.85%)
`build/styles/edit-widgets/style-rtl.css`	4.85 kB	-7 B (-0.14%)
`build/styles/edit-widgets/style-rtl.min.css`	3.52 kB	-6 B (-0.17%)
`build/styles/edit-widgets/style.css`	4.85 kB	-9 B (-0.19%)
`build/styles/edit-widgets/style.min.css`	3.53 kB	-6 B (-0.17%)
`build/styles/editor/style-rtl.css`	30.7 kB	-31 B (-0.1%)
`build/styles/editor/style-rtl.min.css`	26.1 kB	-33 B (-0.13%)
`build/styles/editor/style.css`	30.8 kB	-31 B (-0.1%)
`build/styles/editor/style.min.css`	26.1 kB	-34 B (-0.13%)

_{compressed-size-action}

jasmussen · 2026-06-17T10:02:03Z

I'm happy to support this. I think there will be some future followups with the document title field that we can look at separately, but not something that needs to block this.

In that sense, this generally has my support. However as this is a larger change, I think we ultimately need some green checks from them. Such as @mtias, @youknowriad.

github-actions · 2026-06-17T10:02:44Z

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @lucasmendes-design, @rectang.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Unlinked contributors: lucasmendes-design, rectang.

Co-authored-by: fushar <fushar@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: scruffian <scruffian@git.wordpress.org>
Co-authored-by: tyxla <tyxla@git.wordpress.org>
Co-authored-by: jasmussen <joen@git.wordpress.org>
Co-authored-by: fcoveram <fcoveram@git.wordpress.org>
Co-authored-by: annezazu <annezazu@git.wordpress.org>
Co-authored-by: mikemcalister <mmcalister@git.wordpress.org>
Co-authored-by: m <matt@git.wordpress.org>
Co-authored-by: patric-boehner <patrick-b@git.wordpress.org>
Co-authored-by: mtias <matveb@git.wordpress.org>
Co-authored-by: colorful-tones <colorful-tones@git.wordpress.org>
Co-authored-by: stokesman <presstoke@git.wordpress.org>
Co-authored-by: jhmonroe <jhmonroe@git.wordpress.org>
Co-authored-by: afercia <afercia@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

tyxla

Thanks for addressing the feedback @fushar 🙌

Would be nice to get a last thorough test in all screens, across various screen sizes, to ensure everything works correctly and as expected. I have only done partial testing in the meantime.

Otherwise, my biggest concerns have been addressed already. Makes sense to ask other reviewers who had feedback to re-review.

tyxla · 2026-06-18T11:45:41Z

+	}
+
+	&.is-fullscreen-mode {
+		@include break-medium {


Noticing that the corresponding distraction-free rule in the site editor has no breakpoint, while this one is desktop-only. Is this divergence intentional?

It was, but I think now it's best if they are consistent. The issue is in Post Editor, we always show the admin bar in mobile; the fullscreen mode takes effect only in Desktop 🤔 (hence the breakpoint in the CSS).

With 1b3339e I made Site Editor consistent with the existing Post Editor behavior.

tyxla · 2026-06-18T11:47:29Z

 		if ( previousCanvaMode === 'edit' ) {
-			toggleRef.current?.focus();
+			const desktopToggle = sidebarRegionRef.current
+				? focus.tabbable.find( sidebarRegionRef.current )[ 0 ]


Any chance that the first tabbable element in the sidebar may be different because of a plugin doing something? Should the target be a bit more explicit?

I'm a bit stuck here. Do you have any suggestion? I'd like to target the left chevron (in < Design) but the back button is not part of the layout, so I can't pass the ref like the SiteHubMobile here. Is it OK if I just target that element via DOM query selector here? 🤔

Hmm, a DOM query selector would make things worse. Maybe best to keep it as-is, but just add a comment that we're expecting that the first tabbable element is the Back button. Thanks!

Sure, makes sense: 10dea1c

…stency

…ckButton

scruffian · 2026-06-19T13:43:10Z

 	align-items: center;
 	justify-content: center;
-	background: var(--wpds-color-background-surface-neutral-weak);
+	background: transparent;


I think we can just remove this line.

Suggested change

background: transparent;

Oops, you're right, fixed in 4516c9f; some missed case when trying to merge the CSS from the experiment.

scruffian · 2026-06-19T13:43:15Z

 	align-items: center;
 	justify-content: center;
-	background-color: hsla(0, 0%, 80%);
+	background-color: transparent;


I think we can just remove this line.

Suggested change

background-color: transparent;

Same: fixed in 4516c9f; some missed case when trying to merge the CSS from the experiment.

scruffian · 2026-06-19T13:56:24Z

The site logo is too big on the v2 editor:

fushar · 2026-06-19T14:01:49Z

The site logo is too big on the v2 editor:

Ah are you still enabling the experiment? Try turning that off for now, I think it's a bug 😅 we're trying to port the logic properly here: WordPress/wordpress-develop#11781

I should remove the duplicated feature in the experiment once the Core PR lands.

scruffian · 2026-06-19T14:12:17Z

Some of these buttons aren't working in the extensible editor:

The search button does nothing, the + and home buttons both navigate when they should only show the dropdown.

fcoveram · 2026-06-19T14:35:41Z

Why is the back action different in Post editor and Site editor if both trigger the same action? The Site editor one looks unbalanced when inherits the 64px target area from the previous.

I would simplify it by keeping the Post editor one as it's also used in Design to go back to wp-admin.

fushar · 2026-06-19T14:38:24Z

Why is the back action different in Post editor and Site editor if both trigger the same action?

Yes, that one I'm not 100% sure. But it has a reason. In the Site Editor, we're not actually going back to the "previous" page; we're just showing the shell/chrome. It's also what will be shown when you hover on the W logo icon (before this PR); I'm just reusing that:

fcoveram · 2026-06-19T14:48:00Z

Yes, that one I'm not 100% sure. But it has a reason. In the Site Editor, we're not actually going back to the "previous" page; we're just showing the shell/chrome.

I just tested the following:

When editing a page from wp-admin Pages. I go back to wp-admin Pages.
When editing a page from site admin Pages. I go back to site admin Pages.

The above also applies to Posts in wp-admin and Templates in site admin. So, UX-wise, it is the same action: it goes back to where you're coming from.

fushar · 2026-06-19T14:52:56Z

Some of these buttons aren't working in the extensible editor:
The search button does nothing, the + and home buttons both navigate when they should only show the dropdown.

Nice catch, should be fixed via b5bcc83. But the search button (command palette) is not working on trunk either. Clicking it does nothing:

It's because the command palette is not mounted in the site editor v2. I guess it's never been implemented? In any case I think it should be out of scope of this PR.

fushar · 2026-06-19T14:58:52Z

So, UX-wise, it is the same action: it goes back to where you're coming from.

Hmm yeah, it can be viewed that way as well.

Asking for more input from @lucasmendes-design / @jasmussen. What do you folks think? Should we unify the back buttons in Site Editor and Post Editor to be left chevron (<)?

fushar · 2026-06-19T14:59:56Z

@fcoveram hmm but still, the tooltip says Open Navigation (see my screenshot above), so do we need to update that as well.... (like Go Back)?

fcoveram · 2026-06-19T15:16:04Z

I would go with "Go back" as the tooltip for the action in both editors.

"Open navigation" is confusing as open is usually for diving into the details of a content type, and navigation is already a section where nav menus exist. Also, the current "View [section-name]" will conflict the "View Pages" in wp-admin and site admin.

youknowriad · 2026-06-19T15:48:06Z

It's because the command palette is not mounted in the site editor v2. I guess it's never been implemented? In any case I think it should be out of scope of this PR.

This is not true, the command palette has always worked on site editor v2 (a recent regression is possible though), what I'm not sure about is whether it was WordPress Core that mounted it automatically like any other admin page or whether it was in the "boot" package.

lucasmendes-design · 2026-06-19T17:34:40Z

I'd go with the back button. It's a common action, and I think it's conceptually right.

The other one is not wrong, but I wouldn't introduce another affordance just for this page.

annezazu · 2026-06-20T00:46:20Z

Took this for a quick spin and tried a few things: changing admin color scheme, navigating to Appearance > Fonts, navigating between front end and dashboard, etc. It's all working well in terms of showing up in the right place, working as expected, adapting, etc.

I noticed in the site editor, the alignment feels janky to me between the admin and the overall Design items. It's clear they weren't designed together 😆.

When looking at a smaller viewport, I feel how overwhelming having all of these options might be too. Not sure what we can do there but something to note:

I also noticed when changing around admin scheme, that some show a different shade in the admin bar compared to the default:

I'm not sure if that's intentional but it doesn't help it blend.

github-actions Bot added [Package] Editor /packages/editor [Package] Edit Post /packages/edit-post [Package] Interface /packages/interface [Package] Edit Site /packages/edit-site labels Jun 15, 2026

fushar changed the title ~~Show the admin bar in the Post and Site Editor~~ Show the admin bar in the Post and Site Editor by default Jun 17, 2026

fushar changed the title ~~Show the admin bar in the Post and Site Editor by default~~ Show the admin bar in the Post and Site Editor even on the default fullscreen mode Jun 17, 2026

fushar mentioned this pull request Jun 17, 2026

WordPress 7.1: An omnipresent, consistent admin bar #79036

Open

12 tasks

fushar changed the title ~~Show the admin bar in the Post and Site Editor even on the default fullscreen mode~~ Show the admin bar in the Post and Site Editor in fullscreen mode Jun 17, 2026

fushar force-pushed the omnibar-ungate branch from 34345a2 to 45af02d Compare June 17, 2026 07:38

fushar force-pushed the omnibar-ungate branch from 45af02d to f1a67f5 Compare June 17, 2026 08:10

fushar changed the title ~~Show the admin bar in the Post and Site Editor in fullscreen mode~~ Show the admin bar in the Post and Site Editor by default Jun 17, 2026

fushar force-pushed the omnibar-ungate branch 3 times, most recently from 5ba21e9 to c9aae8c Compare June 17, 2026 08:46

fushar requested review from StevenDufresne, aduth, ciampo, jameskoster, jasmussen, mirka and youknowriad June 17, 2026 09:58

fushar added the [Type] Feature New feature to highlight in changelogs. label Jun 17, 2026

fushar requested a review from tyxla June 17, 2026 10:01

fushar requested a review from mtias June 17, 2026 10:02

fushar marked this pull request as ready for review June 17, 2026 10:02

fushar requested a review from spacedmonkey as a code owner June 17, 2026 10:02

fushar removed the request for review from spacedmonkey June 17, 2026 10:05

fushar added 10 commits June 18, 2026 17:53

Fix tests

4ba994a

Fix test re: keyboard navigation exiting the editor

0ed8144

Fix condition when showing SiteMobileHub

55b7b88

Restore icon prop in FullscreenModeClose

9bad396

Removed unused line in site editor v2

15e30fb

Revert wp-build template changes

b2b7332

Remove unused SiteHub component for desktop

9333fa4

Improve experiment description

4a1227b

Delete more desktop SiteHub references

8524fee

Rename experiment and description

a1af11c

fushar force-pushed the omnibar-ungate branch from a72a11f to a1af11c Compare June 18, 2026 10:55

tyxla reviewed Jun 18, 2026

View reviewed changes

fushar added 2 commits June 19, 2026 14:25

Make Site Editor behaves like Post Editor on < break-medium for consi…

1b3339e

…stency

Add comment that we're expecting the first tabbable to be DashboardBa…

10dea1c

…ckButton

scruffian reviewed Jun 19, 2026

View reviewed changes

Remove redundant background: transparent CSS

4516c9f

Enqueue admin-bar script for site editor v2

b5bcc83

Conversation

fushar commented Jun 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What?

Why?

How?

Testing Instructions

Screenshots or screencast

Post Editor

Site Editor

Site Editor V2

Use of AI Tools

Uh oh!

github-actions Bot commented Jun 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jasmussen commented Jun 17, 2026

Uh oh!

github-actions Bot commented Jun 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Unlinked Accounts

Uh oh!

tyxla left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

scruffian commented Jun 19, 2026

Uh oh!

fushar commented Jun 19, 2026

Uh oh!

scruffian commented Jun 19, 2026

Uh oh!

fcoveram commented Jun 19, 2026

Uh oh!

fushar commented Jun 19, 2026

Uh oh!

fcoveram commented Jun 19, 2026

Uh oh!

fushar commented Jun 19, 2026

Uh oh!

fushar commented Jun 19, 2026

Uh oh!

fushar commented Jun 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fcoveram commented Jun 19, 2026

Uh oh!

youknowriad commented Jun 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lucasmendes-design commented Jun 19, 2026

Uh oh!

annezazu commented Jun 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

fushar commented Jun 15, 2026 •

edited

Loading

github-actions Bot commented Jun 17, 2026 •

edited

Loading

github-actions Bot commented Jun 17, 2026 •

edited

Loading

fushar commented Jun 19, 2026 •

edited

Loading

youknowriad commented Jun 19, 2026 •

edited

Loading