Open matthewbrent opened 5 years ago
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 <BlockControls/>
via SlotFill and exposes the new SlotFill for use with registerPlugin
.
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 https://github.com/WordPress/gutenberg/pull/17198#issuecomment-644452819:
I believe we should be more purposeful about what is placed into Slot locations. Generally speaking, opening a spot to place anything is going to lead to very bad user experience and bad times overall.
This new location should be restricted to the same type of controls that exist now. I propose that the Fill return a
ToolbarItem
that set to use a customDropDown
using aButton
withisPrimary
set to false.In addition to the
className
,classContentName
andposition
related props, the fill will accept a prop for theicon
to display and arenderContent
prop that will be passed to the inner DropDown component. This will keep each item added here standardized and prevent abuse for this Slot.Example implementation:
const render = () => ( <PluginHeaderToolbar className="my-plugin" classContentName="my-plugin-content" position="bottom left" renderContent={() => <div>Content to render</div>} /> ); registerPlugin("my-plugin", { render, icon: "twitter" });
Screenshot:
Screenshot with Block Controls in the Toolbar:
In addition to the changes to SlotFill, I also propose that this slot is only rendered when
isLargeViewport
is true. These items should be considered secondary and treated similarly to the ToolSelector as they are not crucial to content editing.
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
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'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.
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 PluginSidebar
component that is integrated with a menu item in the More Menu and a button in the Pinned Items (on the right). In the footer, they integrate the old interface that was based on meta boxes.
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
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.
AMP's DOM manipulation solution is too hacky
Agreed. And the hacks continue: https://github.com/ampproject/amp-wp/pull/6881#issuecomment-1029245573
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:
edit-post-header-toolbar__left
edit-post-header-toolbar__left
and edit-post-header__settings
edit-post-header__settings
It seems like #17198 only addresses edit-post-header-toolbar__left
.
My use case is that I'd like to add a new button to the edit-post-header__settings
![Screen Shot 2022-03-01 at 10 04 18 AM](https://user-images.githubusercontent.com/484068/156223927-809653dc-8251-4479-9367-4cb0d454e158.png) |
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:
Update
button, which is the most logical place for itgear
icon to restore the normal UI)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)