Toolbar: Display the toolbar in the Site Editor and Block Editor

[lucasmdo]

Problem / Current Behavior

The WordPress Admin Bar (Toolbar) is displayed on the front end and across wp-admin screens, but it is hidden in both the Site Editor and the Block Editor. This creates a navigation inconsistency: users who rely on the Admin Bar as their primary way to move between areas of WordPress lose that affordance the moment they enter either editor.

As WordPress has evolved, the editors have introduced their own navigation patterns, the Site Editor sidebar, the back arrow / WordPress logo button, the Template · Page Title breadcrumb, that differ from the rest of the admin experience. The result is multiple, competing navigation models:

• wp-admin screens: Admin Bar + left sidebar menu.
• Front end (logged in): Admin Bar.
• Site Editor: Custom sidebar (Design panel) with no Admin Bar.
• Block Editor (fullscreen, the default): Custom top toolbar with no Admin Bar and no wp-admin sidebar.

This fragmentation means:

• It is not immediately clear how to exit the editor and return to wp-admin or the front end.
• Users must learn different navigation patterns depending on which screen they are on.
• The Admin Bar, the one element that is consistent across the front end and wp-admin, is absent precisely where users may need it most.

Proposed Enhancement

Display the Admin Bar in the Site Editor and Block Editor, just as it is rendered on wp-admin screens and the front end. The full Toolbar should appear at the top of the viewport, above the editor chrome, preserving all standard nodes and any nodes added by plugins.

This would unify the navigation model across all WordPress contexts:

• wp-admin screens: Admin Bar + left sidebar.
• Front end: Admin Bar.
• Site Editor: Admin Bar + editor sidebar.
• Block Editor: Admin Bar + editor toolbar.

The Admin Bar becomes the single, persistent navigation element users can always rely on.

Rationale

Why Core and not a plugin:

• The Admin Bar is a Core feature and its visibility is a Core decision.
• Navigation consistency across all of WordPress is a platform-level concern, not a plugin concern.
• The current situation, where Core itself hides Core's own navigation element, is an inconsistency that should be resolved in Core.

Who benefits:

• All users: consistent, predictable navigation regardless of context.
• New users: fewer navigation patterns to learn.
• Power users and site administrators: quick access to +New, user menu, and plugin-added toolbar nodes without leaving the editor.
• Plugin developers: toolbar nodes they register via the standard API become available in the editors without extra work.

Supporting context:

Related tickets and issues confirm that editor navigation is a recognized pain point:

• ​Gutenberg #38554: Users requesting Add New access from within the Block Editor, which the Admin Bar already provides.
• ​Gutenberg #72135: Proposal to unify the Site Editor layout, including consistency between admin and editor views.

Backward Compatibility

This change is additive. No existing functionality is removed or altered

Future Considerations

If this enhancement is accepted and implemented, follow-up tickets should be filed to address editor UI adjustments that ensure visual and functional consistency with the Admin Bar present. These may include, but are not limited to:

• Aligning the Block Editor top toolbar layout and spacing with the Admin Bar above it.
• Revisiting the Site Editor sidebar header and back-navigation affordances to complement (rather than duplicate) what the Admin Bar already provides.
• Ensuring responsive behavior on smaller screens accounts for the combined height of the Admin Bar and editor toolbar.

Each of these would be filed as a separate ticket and cross-referenced back to this one.

[fushar]

For now, I added a Gutenberg experiment that shows the admin bar in edtors, in this PR: ​https://github.com/WordPress/gutenberg/pull/77964.

[joedolson]

There are a couple of notable accessibility benefits this could offer:

1) Consistent navigation. Specific elements would always be available in the same location in the page while administering.
2) With the command palette in the adminbar, it could be removed from the editor header. Currently, this has a problematic button, that contains both the editor's h1 with the page title and the shortcut 'Ctrl + K', and does *not* contain any information about the command palette. That h1 should really be separate from the command palette trigger.

But unifying the navigation and design better between the editor and classic admin would be a huge gain.

[jorbin]

I think this is a great idea. In addition to the issues @joedolson mentioned, I think #64762 will also become more important to fix as it will become more prominent.

I am wondering if @joen, @matveb, or @karmatosed might remember why the decision was originally made to exclude the admin bar. I'm struggling to find an issue in the gutenberg repo about it. I want to make sure that whatever the rationale then is considered now.

Moving into the 7.1 milestone for greater visibility and discussion.

[lucasmdo]

Thanks, @jorbin.

I think #64762 will also become more important to fix as it will become more prominent.

+1 on this as well.

[sabernhardt]

The site editor enforced fullscreen mode in GB29489, hiding the admin toolbar and side navigation for everyone.

For the post editor,

• GB9334 / GB9567 created fullscreen mode
• #49574 / GB20611 made fullscreen the default in WordPress 5.4 (see ​dev note and ​Accessibility team's response)

Users can still disable fullscreen mode in the post editor and consistently have both navigation menus.

I think #64762 will also become more important to fix as it will become more prominent.

I tried the Gutenberg experiment and did not find any problems with the color schemes in the site editor or post editor. However, other issues could be prominent more often in the editor(s), including #28983 and #48894. Profile links can cover the Publish/Save button (and other buttons in that corner) if the top-level navigation is overcrowded or if a user hovers over the 'Howdy' link too long (as the cursor moves toward one of the buttons).

[lucasmdo]

For #28983, I proposed a quick solution for this, and it's already working with a plugin, so you can test this out. The idea is to keep nodes accessible on any device and viewport. cc: @sabernhardt

https://core.trac.wordpress.org/ticket/65308

[fushar]

Replying to jorbin:

Moving into the 7.1 milestone for greater visibility and discussion.

Thanks for this. I am working with @lucasmdo to implement the changes. Really excited for this!

I am wondering if @joen, @matveb, or @karmatosed might remember why the decision was originally made to exclude the admin bar. I'm struggling to find an issue in the gutenberg repo about it. I want to make sure that whatever the rationale then is considered now.

Yes, I am struggling, too. I read @sabernhardt's links above, but it seems they are talking about Post Editor, not Site Editor. We can still show the admin bar in Post Editor by turning off Fullscreen Mode. However, that option is removed in Site Editor via GB29489, giving no way for users to show the admin bar there. From what I understand by reading GB29489 and the linked PRs, it's mainly because wp-admin and the Site Editor's sidebars are not compatible. The admin bar is NOT the main reason we removed the option.

I also read the dev note and accessibility team's response as linked above. So many strong arguments against removing the admin bar, which gives me more confidence on this ticket.

With all that being said, I still have one last worry though. What if some users still prefer not to see the admin bar? Fortunately, we have this "Distraction-free" option in both Post and Site Editors. In the implementation, I still hide the admin bar if we turned that option on. So, such users can use that option. I hope that's enough?

In any case, I do believe that this change's benefit outweighs the cons. This really fixes a real user confusion, navigating from and to Site Editor.

---

What's a good next step? Should I start creating a GB PR to apply the changes outside the experiment (remove the experiment gate)?

[lucasmdo]

Great thoughts, @fushar.

So many strong arguments against removing the admin bar, which gives me more confidence on this ticket.

+1. The Admin bar, as a universal menu that helps users navigate between environments, is a great improvement.

From what I understand by reading GB29489 and the linked PRs, it's mainly because wp-admin and the Site Editor's sidebars are not compatible. The admin bar is NOT the main reason we removed the option.

Good to know.

With all that being said, I still have one last worry though. What if some users still prefer not to see the admin bar? Fortunately, we have this "Distraction-free" option in both Post and Site Editors. In the implementation, I still hide the admin bar if we turned that option on. So, such users can use that option. I hope that's enough?

I believe so. I agree that we can hide the Admin Bar in the distraction-free mode. Otherwise it's not a distraction-free mode, right? Users will receive notifications and pings from the Omnibar (plugins, etc). So, it's a way to go for sure.

[afercia]

It is worth reminding that the admin bar is heavily extended by plugins that add their own menus, sub-menus and functionalities.

I'm wondering whether it would be wiser to define first what plugins can and cannot do in the admin bar when it is shown in the block and site editors.

• In the best case, some of the functionalities of these plugins wouldn't do absolutely anything as in: non functional in the block / site editor pages simply because they expect a classic admin page based on PHP.
• In the worst case, some of these plugins functionality may break the editors or trigger data loss.

The above should be carefully considered as the admin bar is rarely a 'clean' one as in: the one generated by a fresh WordPress install. Instead, it's often bloated by plugin menus and functionalities.

Focus management is one more concern as the block / site editors do use their own focus management mechanisms that do not expect the admin bar to be there.
If the admin bar gets added, keyboard navigation should start from the admin bar and follow a natural tab order.

From a design / UI perspective, first couple things that come into my mind are:

• The UI would show two buttons / links with a 'WP' icon, these controls have different purposes and functionalities so the design should be changed.
• The UI would show two controls to open the command palette, so that thre design should be changed.

See attached screenshot.

[fushar]

Replying to afercia:

Thanks for the comments!

I'm wondering whether it would be wiser to define first what plugins can and cannot do in the admin bar when it is shown in the block and site editors.

• In the best case, some of the functionalities of these plugins wouldn't do absolutely anything as in: non functional in the block / site editor pages simply because they expect a classic admin page based on PHP.
• In the worst case, some of these plugins functionality may break the editors or trigger data loss.

I think we should be fine. Today, the Post Editor and Site Editors already load and render the admin bar -- it's just that it's hidden by CSS (via display: none) when the "Fullscreen mode" is enabled. If a plugin would break editor, it would have broken it by now already.

--

Focus management is one more concern as the block / site editors do use their own focus management mechanisms that do not expect the admin bar to be there.
If the admin bar gets added, keyboard navigation should start from the admin bar and follow a natural tab order.

Thanks, I'll make sure to verify the correct tab order behavior!

--

From a design / UI perspective, first couple things that come into my mind are:

• The UI would show two buttons / links with a 'WP' icon, these controls have different purposes and functionalities so the design should be changed.
• The UI would show two controls to open the command palette, so that thre design should be changed.

See attached screenshot.

They have already been taken care of :) the W icon in the editor is being replaced by a back button, and the duplicated cmd palette icon is being removed. See the following screenshot.

[afercia]

if a plugin would break editor, it would have broken it by now already.

Not sure. I'm mostly concerned about users having access to features and actions provided by plugins in those admin bar menus that could potentially break the user experience and the editor.

Consider for example a plugin like 'View Admin As'. When you switch to another user role, it triggers a page reload, which isn't the best experience in an editing context and may potentially expose to data loss.

Other plugins may provide features and actions that trigger more serious effects and disrupt the editor entirely..

I still strongly recommend to carefully investigate potential breakages triggered by plugins here.

One option could be to remove any custom menu from the admin bar on the editor pages.
Another option could be introducing a 'support' flag for plugins that want to add menus in the editor pages or that declare them 'safe' to be used in the editor context.

Overall, the statement that 'we should be fine' because the Post Editor and Site Editors already load and render the admin bar and we didn't notice breakages so far sounds a little optimistic to me and I'd argue it's a statement that isn't based on any testing so far. It's not just about the presence of plugin-added menus. It's the actions those menus provide.

Such a change should be committed very early in a release cycle and a call for testing should be made widely public.

the W icon in the editor is being replaced by a back button,

Glad to hear about that. It's something I asked for since a long time, see for example ​https://github.com/WordPress/gutenberg/issues/57813. See also a comment there from a certain 'm' user: ​https://github.com/WordPress/gutenberg/issues/57813#issuecomment-1897059789

[fushar]

Replying to afercia:

Overall, the statement that 'we should be fine' because the Post Editor and Site Editors already load and render the admin bar and we didn't notice breakages so far sounds a little optimistic to me and I'd argue it's a statement that isn't based on any testing so far.

I'm not sure if I understand this statement. In the Post Editor, users can already show the admin bar by turning off the Fullscreen mode (see the next screenshot). Wouldn't it then be already an issue in existing WordPress behavior, and not introduced by the proposed change?

[dufresnesteven]

Not to speak on their behalf, but my understand is that @afercia is pointing out that while the admin bar is currently available in the Post editor today, turning it on by default for all WordPress users will expose significantly more users to potentially broken experiences due to actions driven by the admin bar.

Other plugins may provide features and actions that trigger more serious effects and disrupt the editor entirely..

I still strongly recommend to carefully investigate potential breakages triggered by plugins here.

Such a change should be committed very early in a release cycle and a call for testing should be made widely public.

Assuming there is significant risk in this change, which I'm not certain there is, I'm less optimistic that an earlier call for testing would be able to close the gap effectively. I think the release candidate cycle is where the majority of testing occurs and anything critical identified in that stage could be removed should that be the case.

I think the tension is why rush vs why wait? While I'm also sensitive to relying on "it should be fine" without clearly demonstrated testing, I also don't see any evidence in the other direction where this is a demonstrably risky change, although I get the admin bar is a random collection of history and dodgy code.

We're not inheriting the history of all plugins, the admin bar was on be default until WordPress 5.4 without concern.

Ref: ​https://make.wordpress.org/core/2020/03/03/fullscreen-mode-enabled-by-default-in-the-editor/

[afercia]

I'm not sure if I understand this statement. In the Post Editor, users can already show the admin bar by turning off the Fullscreen mode (see the next screenshot). Wouldn't it then be already an issue in existing WordPress behavior,

You are right, I should have better clarified that it is already a problem in the Post Editor. I forgot because I tend to keep the default 'full screen' mode.

[sabernhardt]

This needs more time to prepare for it.

[dufresnesteven]

This needs more time to prepare for it.

Can you provide a clear list of things that need to be prepared so we can effectively derisk? I don't see the reason for why this needs to be delayed.

[joedolson]

@sabernhardt Have you been following ​https://github.com/WordPress/gutenberg/issues/79036? This has actually been largely completed, although I don't think the linkage between this ticket and that PR have been well tracked.

[lucasmdo]

I also don't see any evidence in the other direction where this is a demonstrably risky change, although I get the admin bar is a random collection of history and dodgy code [...] We're not inheriting the history of all plugins, the admin bar was on be default until WordPress 5.4 without concern.

+1. Most plugins open a dropdown panel on hover or redirect people to another page on click (which we can use the native modal on the browser to prevent that ​https://cleanshot.com/share/ptL2ZC1c)

Can someone clarify the risk here? Maybe I'm missing something.

[lucasmdo]

@sabernhardt could you change it back to the current 7.1 release?

[lucasmdo]

Sorry @joedolson, I think we've made a comment at the same time and because of that I reverted the release for the future release. I'm fixing the error now.

[sabernhardt]

Most plugins open a dropdown panel on hover or redirect people to another page on click (which we can use the native modal on the browser to prevent that)

I tried clicking the top-level Add New (Post) and Howdy profile links in the site and post editors after making some change to block settings or content, and I already received the browser warning in Firefox. However, if the omnipresent toolbar introduces another way to lose content, that would be a blocker.

The experience of opening the toolbar's dropdown menus when hovering near the common buttons such as Publish and Save should be more of a nuisance than a risk. If you do it often, that would result in increasing frustration.

If the toolbar overflows its container, top-level links can obstruct editor controls, and that needs a remedy before showing the toolbar more often. Hiding the overflow, except on hover or focus within, might be an adequate short-term solution. (It is not elegant, and it still has the same problem as expanding dropdowns on hover.)

#wpadminbar {
	overflow-y: hidden;
}
#wpadminbar:hover,
#wpadminbar:focus-within {
	overflow-y: visible;
}

@joedolson mentioned during ​last week's bug scrub "adding a flag that extenders can use to omit from the site editor or from the post editor" (unless that is already possible). I was unsuccessful with my attempts using $current_screen->is_block_editor(), but someone should document the proper procedure, whether it is new or existing.

[lucasmdo]

Got it. I lean toward keeping the Admin Bar as it is for now.

For the content loss concern, your own test is reassuring. You made changes, clicked Add New and Howdy, and the browser warning fired in both editors. So the native guard already works.

The hover dropdowns feel similar to me. The panels only open on hover, they're not persistent, so it's more of a small issue than a real risk. If it turns out to be annoying in practice, we can tune hover intent or spacing, but I'd keep it as it is for now and check the behavior in real use.

[fushar]

Replying to sabernhardt:

The experience of opening the toolbar's dropdown menus when hovering near the common buttons such as Publish and Save should be more of a nuisance than a risk. If you do it often, that would result in increasing frustration.

I would say this is a sign for us to reconsider the behavior of the admin bar menus to open on click instead of on hover. This is already an issue in other screens as well, though I agree that it is more visible on editor screens where the Save button is near the top. I think there's plenty of Trac tickets already about this (e.g. https://core.trac.wordpress.org/ticket/48494).

@joedolson mentioned during ​last week's bug scrub "adding a flag that extenders can use to omit from the site editor or from the post editor" (unless that is already possible). I was unsuccessful with my attempts using $current_screen->is_block_editor(), but someone should document the proper procedure, whether it is new or existing.

Did you / @joedolson meant something like this? This is a plugin that renders an admin bar node on all screens except the Post / Site editors. I tested and it seems to work well.

<?php
/**
 * Plugin Name: Non-Editor Node Demo
 * Description: Adds an admin bar node that appears everywhere except the post/site editor.
 * Version:     1.0.0
 * Author:      Demo
 */

defined( 'ABSPATH' ) || exit;

add_action(
      'admin_bar_menu',
      function ( WP_Admin_Bar $wp_admin_bar ) {
              $screen = function_exists( 'get_current_screen' ) ? get_current_screen() : null;

              if ( $screen && $screen->is_block_editor() ) {
                      return;
              }

              $wp_admin_bar->add_node(
                      array(
                              'id'    => 'non-editor-node',
                              'title' => 'Non-editor node',
                              'href'  => admin_url(),
                      )
              );
      },
      100
);

And yes, we can document this in a dev note.

[joedolson]

Yes, that's the type of thing I was referring to @fushar. Thank you!

[fushar]

This feature has been fully implemented in ​https://github.com/WordPress/gutenberg/pull/79197. It seems Trac can only link PR to wordpress-develop repo, and not Gutenberg, so the link between this ticket and that PR might have not been clear. It will land in Core only after we update the GB SHA to the latest / 23.6 version.

So I'm not sure what's the next step for this ticket -- should we close it now, or later at that time? (I still need to write the dev note, too)

[wildworks]

So I'm not sure what's the next step for this ticket -- should we close it now, or later at that time? (I still need to write the dev note, too)

If there is nothing else to address regarding this ticket at this time, I believe it is okay to close it, even if the dev note is not yet ready. I have reviewed several past tickets and found some cases where the dev note was added after the ticket was closed by a commit.

[fushar]

Got it, thanks @wildworks.

BTW, a draft of the dev note is here: ​https://docs.google.com/document/d/10dBdxF5CIihE126-Mi4kYarOqWTMO8sAaIBrxo8ZUl8/. Anyone is welcome to review it. Thanks in advance!

[wildworks]

@fushar, Regarding the 7.1 release, are there any other issues that need to be addressed at this time? If not, let's close this ticket. If any new bugs are found, we can address them in a new ticket.

[fushar]

Nope, we're good for 7.1, thanks for checking. Let's close this ticket, somehow I can do it, let me do it.

[sabernhardt]

Dev note:
​https://make.wordpress.org/core/2026/07/13/consistent-navigation-in-wordpress-7-1-with-persistent-toolbar/