-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Add a SlotFill to Toolbar in the header #16988
Comments
If I get some time I'd be willing to make a PR if that would help? |
It would be nice to have a slot fill for:
|
I've done a PR that adds the |
As further background on the desire for a solution like is proposed in this issue, the following plugins are examples that currently integrate functionality into the admin bar:
There are also newly released plugins that are integrating with the admin bar (e.g., Accessible Content from CampusPress) so this is an issue that will continue to expand in impact as other plugins integrate with the admin bar without an obvious replacement in Gutenberg's fullscreen mode. I'll also note that there are plugins that are finding other ways to integrate with Gutenberg's fullscreen mode in lieu of the admin bar (e.g., Yoast integrating into both the sidebar and below the content editor), but without a standard recommendation from the Gutenberg team on how to pivot from the admin bar into a Gutenberg-first world we'll likely see a wide variety of integrations that create a disjointed and confusing experience. So while I can appreciate the desire to hold off on opening up a slotfill in Gutenberg's header to allow for time to consider all options, we must also consider that in lieu of a slotfill that we provide a best practice recommendation to plugins that currently integrate with the admin bar on how to replicating that functionality into Gutenberg. Making this sort of recommendation will go a long way in ensuring a standard UX for users expectation for plugins functionality within Gutenberg. |
Let me reshare first the latest proposal from @ryanwelcher included in #17198 (comment):
|
I think it's rather an issue that was created when the full-screen mode was set as the default mode. I know that there are some explorations that seek to make it easier to make the admin bar visible. Anyway, it's only slightly related because it's hard to tell how many of those integrations make sense in the context of the editing content on a currently open page.
I think Yoast is a good example of how integration should look like. They were involved in the development process and largely influenced what is possible today. They use I understand the need for more integrations and I personally discussed many times some ideas for SlotFill based plugin:
I would like to understand what types of extensions are missing before we go into the specifics where to put them. What @ryanwelcher proposed is quite close to what More Menu is, it's just in a different place. I'm not against making it possible to put plugin integrations in other places, but maybe we could use one API and only introduce a new prop in the existing plugin components that would allow developers to render them in a different context. |
Adding an additional voice in here for allowing for SlotFill patterns used more globally. As others have already surfaced - some of the bigger pain points our publishing clients are experiencing in switching from the classic editor to Gutenberg include having top-level, global controls available in a first-class slot, right, where they'd expect them. Especially what other have called the "Header Left" section - not having that be a fillable slot seems like a significant oversight. |
The AMP plugin currently adds a button to the right of the preview button This is their solution for that: https://github.com/ampproject/amp-wp/blob/81b9df742d9f78fb5ee3657622d21eb8c7926f64/assets/src/block-editor/plugins/wrapped-amp-preview-button.js |
There is a very promising PR #31984 from @delawski that makes the Preview dropdown extensible. In the future, the AMP plugin could use a more formal approach for preview when the functionality is available. Anyway, that you for sharing the use case and the approach that plugins currently take. |
Just want to bump this issue. I've come across the need to add buttons to the toolbar many times since I commented in 2019. AMP's DOM manipulation solution is too hacky (sorry @westonruter and @pierlon) to be a permanent solution. @ryanwelcher's PR may need a refresh, but it looks like a good approach to me. |
Agreed. And the hacks continue: ampproject/amp-wp#6881 (comment) |
We're doing something similar at Extendify to add a button to the toolbar. Elementor does itself as well, Stackable — quite a few others too. I think we should perhaps have a slot that can be used instead to clean up these additions, reduce conflicts, and also build in a method for users to turn toolbar items off/on via the Preferences modal (like we have for the block manager perhaps). A rough-cut visual: |
To clarify, it seems like there's several things discussed here that are related, but somewhat independent of each other:
It seems like #17198 only addresses |
My use case is that I'd like to add a new button to the It's similar to Jeff's Distributor plugin, where a multisite has a canonical version of a post, and other sites "fork" it, but sometimes it's desirable to sync them. It seems like the current recommendation is to follow what Yoast/Jetpack do, but I feel like that has several problems:
|
It seems like one of the blockers to this and other new slots is the lack of room in the UI. I don't understand why that has to be a problem, though. Could we adapt the mobile layout to the device and the fills, rather than trying to make it use the desktop layout? For example, the "left", "center", and "right" areas of the toolbar could each have their own row, and then we wouldn't have to hide features from users, or block extensibility. Are there tradeoffs that aren't obvious to me, or something else I'm missing? |
Any Updates on this? currently having to solve this exact issue and i am not sure if i should do it myself or just wait |
Is your feature request related to a problem? Please describe.
Currently Several SlotFills exist in the editor application. Some are wrapped as plugins and others are not. It is currently possible to add a Fill/Plugin to the right hand side of the toolbar, next to where the inspector toggle is. There are none for the left hand side of the toolbar where the add block button is.
Currently the Block Menu can be added to this area by enabling the Top Toolbar setting in the more tools and options ellipsis menu in the top right however, after reading the source, this appears to be added to the toolbar using a boolean flag rather than the SlotFill
see the line here
Describe the solution you'd like
Refactor the Header Toolbar to replace the conditional logic that renders the BlockToolbar with a SlotFill that will both make sense from a refactor and also make it possible to add more Fills to this location (and also allow a plugin for this location at a later date)
The text was updated successfully, but these errors were encountered: