-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Editor Top Toolbar display issues From Gutenberg 16.x #79769
Comments
6559005-zd-woothemes |
Support References This comment is automatically generated. Please do not edit it.
|
Just want to note that this PR will fix the problem: WordPress/gutenberg#52722 Available in Gutenberg 16.4. |
📌 NOTE
If users need a workaround in the meantime, they can turn off the Top Toolbar and use the block toolbar instead. |
6540504-zd-woothemes |
6580703-zd-woothemes We worked on a different issue with the user, but I noticed the same error. |
GB 16.4 went out today but this was backported to 6.3 previously. Thus far, I can't replicate on WPCOM, unless I make the screen size a bit smaller: top.toolbar.movOverall though, this problem should be resolved in most cases. Can someone confirm? |
Hey @annezazu ! I took a few recordings of the behavior I'm seeing on WPCOM, as well as on my self-hosted site for reference. I am not positive of what the intended behavior is as the top bar responds to narrowing screen sizes, so I didn't want to assume what was expected and what wasn't! Here are the highlights: ON WPCOM
OUTSIDE OF DOTCOM
Free Edge site - 16.4.0-rc.1 4uAzdO.mp4Atomic - WP 6.3 + Gut 16.3 zMUDNC.mp4Atomic - WP 6.3 + Gutenberg 16.4 voBHZ5.mp4Atomic - WP 6.3 + Gutenberg 16.4, with Yoast installed (per OP example) efRV9Y.mp4For comparison: Pressable Site - WP 6.3 + Gutenberg 16.4, all other plugins inactive kvu4dV.mp4 |
This is very helpful! Thank you. @draganescu can you follow up here? |
Yes - thank you for the very helpful and detailed issue. I'm sorry for the hassle. They're known limitations of the current implementation which can't know how many pinned items are on the right of the header so with all the tweaking some overlap is bound to happen. We're working to figure out the overall changes required to allow for a better implementation which places the toolbar in a flow context that does not overlap neighboring UI. |
I made WordPress/gutenberg#53526 for some options around sizing the toolbar when many plugins are enlarging the right side of the header. |
Merged into Core here: Closing 👍 |
Quick summary
With Top Toolbar selected, the bar “takes over” more horizontal space than expected in GB 16.x
A video (self-hosted) and screenshot (WPcom + Yoast) follow. Both browsers were at 1280px wide:
Self-hosted video:
84bdqr.mp4
WPcom + Yoast image:
As you can see, the default expanded state covers the
Save Draft
/Update
buttons, and preview icon + some of thePublish
button.With plugins that add elements to the top bar active (Yoast in this case), the effect is more pronounced and looks like a glitch to the untrained eye.
Steps to reproduce
What you expected to happen
I expected the toolbar to cover other elements on the right of the editor when necessary (lots of options).
What actually happened
Buttons on the right of the top toolbar were unecessarily covered.
Impact
All
Available workarounds?
No but the platform is still usable
Platform (Simple and/or Atomic)
Simple, Atomic, Self-hosted
Logs or notes
I raised this in Slack via: p1690077406281749-slack-C0160HSMDQV
There is a companion issue in Core here: WordPress/gutenberg#52688
I've created this report for WPcom HEs who come across this issue and want to record interaction IDs/have some additional context.
The text was updated successfully, but these errors were encountered: