Add experiment to show admin bar in Post and Site Editor#77964
Open
fushar wants to merge 22 commits into
Open
Conversation
github-actions
Bot
added
[Package] Edit Post
|
Size Change: +6.72 kB (+0.08%) Total Size: 7.95 MB 📦 View Changed
ℹ️ View Unchanged
|
fushar
force-pushed
the
admin-bar-in-editor-experiment
branch
from
5f86fee to
02f78b0
Compare
|
Flaky tests detected in b7ba419. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/25842775912
|
fushar
force-pushed
the
admin-bar-in-editor-experiment
branch
2 times, most recently
from
5e4770b to
543c14f
Compare
|
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
tyxla
reviewed
May 7, 2026
| */ | ||
| function gutenberg_add_admin_bar_in_editor_body_class( $classes ) { | ||
| $screen = get_current_screen(); | ||
| if ( ! $screen || ! gutenberg_is_experiment_enabled( 'gutenberg-admin-bar-in-editor' ) ) { |
Member
There was a problem hiding this comment.
It doesn't seem like we're checking for is_admin_bar_showing() at all.
There's a chance that a plugin or a theme is altering the core behavior (plus there are a few edge cases that the function is covering by default). Also, the user can disable the admin bar from their profile from the "Show Toolbar when viewing site" setting (also covered by that function).
Sounds like something to consider here, in addition to the screen and experiment checks?
Contributor
Author
There was a problem hiding this comment.
Thanks, I forgot about that function. Added here: 813b065
| } | ||
|
|
||
| return ( | ||
| ( 'post' === $screen->base && $screen->is_block_editor() ) || |
Member
There was a problem hiding this comment.
Is the post screen check necessary?
Contributor
Author
There was a problem hiding this comment.
Yes it is. I refactored here to make it clearer: a90027b
| } | ||
|
|
||
| const isAdminBarInEditorEnabled = | ||
| globalThis.document?.body.classList.contains( |
Member
There was a problem hiding this comment.
Is there another way that doesn't require relying on working with DOM?
One way that comes to mind is the experiment declaring a window.__experimentalFoo global var, like many others do, and then checking for that here. This can allow us to fold in additional server side logic that could help you address the other comment I left above.
Contributor
Author
There was a problem hiding this comment.
Sure. Changed here: 1118287.
I need to add it on admin_enqueue_scripts and not in the existing admin_init block above it. Because the is_admin_bar_showing() needs admin initialization to be finished first.
Comment on lines
+64
to
+65
| opacity: 1 !important; | ||
| transform: none !important; |
Member
There was a problem hiding this comment.
Would be great to have fewer new (none) !important clauses. Is this because of the framer variants? Should we find a different way to disable those?
Contributor
Author
There was a problem hiding this comment.
Yes, it's becuase of the <motion>. The CSS changes were somehow the results of my previous attempt to make the changes CSS-only. But yeah I think modifying the DOM itself would be better going forward. See 6c90863. Though it's a bit more complex. What do you think 🤔
| ), | ||
| array( | ||
| 'id' => 'gutenberg-admin-bar-in-editor', | ||
| 'label' => __( 'Toolbar in editor', 'gutenberg' ), |
Member
There was a problem hiding this comment.
Is it admin bar or toolbar? Should this also be reflected in internal naming?
Contributor
Author
There was a problem hiding this comment.
I believe the user-facing term is Toolbar. See Users -> Profile for example:
Member
There was a problem hiding this comment.
Yeah, my comment was about the internal naming (the variables / names we use). Not a blocker of course
| } | ||
| } | ||
|
|
||
| &:has(.editor-editor-interface.is-distraction-free) { |
Member
There was a problem hiding this comment.
Do we need an extra test to cover distraction free?
| variants={ ! disableMotion && toggleHomeIconVariants } | ||
| > | ||
| <Icon icon={ arrowUpLeft } /> | ||
| <Icon icon={ backIcon } /> |
Member
There was a problem hiding this comment.
The back icon swap could be yet another thing to have a test for.
Contributor
Author
There was a problem hiding this comment.
It's hard to add visual test for icon. There's no stable semantic role for it. 🥹
What I did is to ensure the top-left button is still rendered in all cases: 860026e
fushar
force-pushed
the
admin-bar-in-editor-experiment
branch
5 times, most recently
from
ba11c1b to
728dc74
Compare
tyxla
reviewed
May 8, 2026
Member
tyxla
left a comment
tyxla
left a comment
There was a problem hiding this comment.
Thanks for addressing the feedback, I think it's looking much better.
I still think there are a couple of good opportunities before we land it, see my inline comments.
My biggest concern is the lack of isolation and unconditional loading of the new styles. Luckily, there is an elegant solution.
Comment on lines
+52
to
+53
| wp_add_inline_script( 'wp-edit-post', 'window.__experimentalAdminBarInEditor = true', 'before' ); | ||
| wp_add_inline_script( 'wp-edit-site', 'window.__experimentalAdminBarInEditor = true', 'before' ); |
Member
There was a problem hiding this comment.
It's very common to add such inline scripts to the wp-block-editor package (see gutenberg_enable_experiments()). Is there a reason not to add it there? It would also be a single line, single script, not two lines and two scripts.
Contributor
Author
There was a problem hiding this comment.
gutenberg_enable_experiments() adds the logic in admin_init action. However, our experiment needs to run in admin_enqueue_scripts, because it needs to wait until is_admin_bar_showing() returns the correct value before setting the window.__experimentalAdminBarInEditor.
Updated here: 005c397 to move to wp-block-editor, but I refactored it again later to extract the CSS logic.
| */ | ||
| function gutenberg_add_admin_bar_in_editor_body_class( $classes ) { | ||
| return gutenberg_is_admin_bar_in_editor_experiment_enabled() | ||
| ? $classes . ' is-admin-bar-in-editor-enabled' |
Member
There was a problem hiding this comment.
I see the sole reason to keep the body class now is the CSS overrides. Should we drop it and just move all that CSS to a separate stylesheet and just enqueue it conditionally? I think that would offer the best of both worlds.
Contributor
Author
There was a problem hiding this comment.
Makes sense! I refactored and made the changes here: daff6c7
| } | ||
| } | ||
|
|
||
| body.js.block-editor-page.is-fullscreen-mode.is-admin-bar-in-editor-enabled { |
Member
There was a problem hiding this comment.
All this CSS will have to be loaded in production, regardless of the experiment.
I think a better idea is to move it to a separate stylesheet and enqueue it conditionally, only when the experiment is enabled (and the rest of the conditions are matched).
As mentioned above, that could also potentially remove the need for the extra body class.
Note that this comment applies to any CSS that is namespaced to this classname.
| justify-content: center; | ||
| width: $button-size-compact; | ||
|
|
||
| .components-button { |
Member
There was a problem hiding this comment.
Component overrides are never a great idea 😬 What else could we do?
Contributor
Author
There was a problem hiding this comment.
Sorry it's a leftover from my own testing -__- unused. Removed in 8442edd.
| body.js.site-editor-php { | ||
| background: $gray-900; | ||
|
|
||
| &.is-admin-bar-in-editor-enabled { |
Member
There was a problem hiding this comment.
More CSS to potentially move to a separate stylesheet 😉
tyxla
reviewed
May 8, 2026
| </Button> | ||
| { isAdminBarInEditorEnabled ? ( | ||
| <div className="edit-site-editor__back-icon"> | ||
| <Icon icon={ arrowUpLeft } /> |
Member
There was a problem hiding this comment.
I see we're handling RTL instances in the full screen mode, should we do the same here?
Contributor
Author
There was a problem hiding this comment.
Right. Fixed in 8442edd (and all RTL-related comments).
| > | ||
| <SiteIcon className="edit-site-layout__view-mode-toggle-icon" /> | ||
| { isAdminBarInEditorEnabled ? ( | ||
| <Icon icon={ arrowUpLeft } size={ 48 } /> |
Member
There was a problem hiding this comment.
I see we're handling RTL instances in the full screen mode, should we do the same here?
visibility via CSS
Member
|
Your rationale on the needs for specificity and lack of SCSS for these stylesheets makes sense, thanks for elaborating. From my perspective, all feedback has been addressed. I think you just need to have someone to finally test it and give it a 🟢 . |
Contributor
Author
|
Thanks for the great reviews. Have a good break! |
youknowriad
reviewed
May 11, 2026
Contributor
youknowriad
left a comment
youknowriad
left a comment
There was a problem hiding this comment.
Did we consider the new experimental site editor and what needs to be done there when both experiments are enabled?
| @@ -0,0 +1,65 @@ | |||
| .edit-post-fullscreen-mode-close__view-mode-toggle { | |||
Contributor
There was a problem hiding this comment.
Why is this css file in lib instead of in edit-post?
| @@ -0,0 +1,71 @@ | |||
| body { | |||
Contributor
There was a problem hiding this comment.
Why is this css file in lib instead of in edit-site?
| $handle = 'gutenberg-admin-bar-in-editor-edit-post'; | ||
| $style_path = 'lib/experimental/admin-bar-in-editor/edit-post.css'; | ||
| $dependencies = array( 'wp-edit-post' ); | ||
| } |
Contributor
There was a problem hiding this comment.
Why are these two separate stylesheets instead of something using a global class name and the CSS files part of the package directly?
Contributor
Author
Contributor
There was a problem hiding this comment.
I would do a separate css file in the package and import it in the main style of edit-post and edit-site. Yes, it requires an extra classname but I think it's simpler and we can probably use ":where" to keep the specificity lowish. That would be my preference, as this PR as it stands will make the core backport more complex.
Contributor
Author
There was a problem hiding this comment.
Makes sense, updated in 2db28b1. Now I added has-admin-bar-in-editor body class.
I tried :where but it won't work because the @use imports will inject the imported CSS above the main CSS in the file, so it will lose in specificity to the main CSS which comes later.
fushar
commented
May 12, 2026
Contributor
Author
There was a problem hiding this comment.
Did we consider the new experimental site editor and what needs to be done there when both experiments are enabled?
I missed this. OK now I have a fix, which will be in a separate css file according to the current approach 😬 so let's have a consensus on how to move forward with that.
| Before | After |
|---|---|
 |
 |
| $handle = 'gutenberg-admin-bar-in-editor-edit-post'; | ||
| $style_path = 'lib/experimental/admin-bar-in-editor/edit-post.css'; | ||
| $dependencies = array( 'wp-edit-post' ); | ||
| } |
Contributor
Author
Contributor
|
Make sure to also test the "font library" page under appearance. |
fushar
force-pushed
the
admin-bar-in-editor-experiment
branch
from
fff9469 to
5642908
Compare
fushar
commented
May 12, 2026
Contributor
Author
fushar
left a comment
fushar
left a comment
There was a problem hiding this comment.
Did we consider the new experimental site editor and what needs to be done there when both experiments are enabled?
Fixed via 5642908. It's a bit complex to set up the admin bar because it seems the new site editor v2 has different WP page loading lifecycle 🤔
Make sure to also test the "font library" page under appearance.
Tested and nothing breaks!
| $handle = 'gutenberg-admin-bar-in-editor-edit-post'; | ||
| $style_path = 'lib/experimental/admin-bar-in-editor/edit-post.css'; | ||
| $dependencies = array( 'wp-edit-post' ); | ||
| } |
Contributor
Author
There was a problem hiding this comment.
Makes sense, updated in 2db28b1. Now I added has-admin-bar-in-editor body class.
I tried :where but it won't work because the @use imports will inject the imported CSS above the main CSS in the file, so it will lose in specificity to the main CSS which comes later.
youknowriad
reviewed
May 12, 2026
Contributor
The background color of the admin bar is different than the rest of the site editor. That doesn't seem intentional. |
Contributor
User profiles look particularly bad, should the site editor adapts its background as well? |
Contributor
|
same issue in the font library and site editor v2 
|
fushar
force-pushed
the
admin-bar-in-editor-experiment
branch
3 times, most recently
from
f69c744 to
c187ddd
Compare
fushar
force-pushed
the
admin-bar-in-editor-experiment
branch
from
c187ddd to
d44f9ec
Compare
Contributor
Author
Good catch, I forgot about color schemes 😅 fixed via 221bc4f. Now the color schemes are applied in all pages you mentioned above. I attached screenshots of the site editor on all color schemes in the PR description. Not sure if it's the best solution. Basically we need to duplicate the color scheme definitions from Core, which are hardcoded, as new variables, then use the variables in the CSS. |
fushar
force-pushed
the
admin-bar-in-editor-experiment
branch
from
d4f6331 to
5cabe16
Compare
Contributor
|
I can't find my previous comments on the commit about the color schemes, so I don't know if you replied, Github UI is so broken. |
Contributor
Author
|
Here's your comments. I think it's broken because the comments were on a specific commit: Now I think the color schemes are NOT independent of this experiment. I mean I believe this experiment does need the site editor sidebar to match the admin bar. Otherwise in certain color schemes it will look very weird. What's independent is that whether the sidebar should match the admin bar color when the experiment is off (or this behavior never lands as default behavior). I'll create a separate PR for that; I think how color schemes work needs more discussion. |
Contributor
Author
|
@youknowriad any more objection to merging this? 😄 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Trac ticket: https://core.trac.wordpress.org/ticket/65091
What?
This PR adds a Gutenberg experiment to show the admin bar (a.k.a. Toolbar) in fullscreen Post and Site Editor.
See this Trac ticket for more context: https://core.trac.wordpress.org/ticket/65091.
Why?
We want to test an editor experience where we keep the admin bar and show a clearer button that exits the editor. We want to avoid users from getting lost in the fullscreen editor.
How?
This PR registers a new
gutenberg-admin-bar-in-editorexperiment.The admin bar is actually printed in the HTML all along, but hidden/covered by the fullscreen editor. So, if the experiment is enabled, the
<body>gets a new CSS class,.is-admin-bar-in-editor-enabled, which adjusts some CSS so that the admin bar is uncovered.This PR also replaces the top-left site icon with an explicit back button, which makes it clearer how to exit the editor. No information is lost because we show the site name in the admin bar.
Testing Instructions
Testing Instructions for Keyboard
The admin bar elements and site editor can still be reached using keyboard (tabs).
Screenshots or screencast
Site Editor
Post Editor
Site Editor on various admin color schemes(reverted, will be in a separate PR)See: #78331
Use of AI Tools
I used Codex which helped me implement this feature.