Add a SlotFill to Toolbar in the header

[matthewbrent]

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)

[matthewbrent]

If I get some time I'd be willing to make a PR if that would help?

[lukecarbis]

It would be nice to have a slot fill for:

• Header Left
  • Inserter
  • Undo
  • Redo
  • Table of contents
  • Navigation
• Header Center
• Header Right
  • Post publish
  • Settings
  • More menu

[ryanwelcher]

I've done a PR that adds the <BlockControls/> via SlotFill and exposes the new SlotFill for use with registerPlugin.

[jeffpaul]

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:

• Site Kit by Google: 400,000+ active installs and 3,054,354 downloads
• Query Monitor: 100,000+ active installs and 2,285,090 downloads
• Debug Bar: 30,000+ active installs and 845,770 downloads
• Toolbar Extras for Elementor: 20,000+ active installs and 219,797 downloads
• Admin Bar User Switching: 2,000+ active installs and 22,450 downloads
• Distributor: disclaimer that I personally oversee this plugin as part of my job

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.

[gziolo]

Let me reshare first the latest proposal from @ryanwelcher included in #17198 (comment):

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 custom DropDown using a Button with isPrimary set to false.

In addition to the className, classContentName and position related props, the fill will accept a prop for the icon to display and a renderContent 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.

[gziolo]

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:

• menu item in More Menu + button in the pinned item that opens a modal dialog – similar to the existing Copy All Content
• menu item in More Menu + button in the pinned item that executes an action – similar to Block Manager or Keyboard Shortcuts
• there was also this proposal from @jasmussen to have full-screen takeover 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.

[JustinSainton]

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.

[PypWalters]

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

[gziolo]

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.

[lukecarbis]

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.

[westonruter]

AMP's DOM manipulation solution is too hacky

Agreed. And the hacks continue: ampproject/amp-wp#6881 (comment)

[richtabor]

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:

[iandunn]

To clarify, it seems like there's several things discussed here that are related, but somewhat independent of each other:

• Add a Slot for edit-post-header-toolbar__left
• Add a Slot for the center area between edit-post-header-toolbar__left and edit-post-header__settings
• Add a Slot for edit-post-header__settings
• Admin bar customizations are hidden in fullscreen mode, some of which are related to post editing (and some aren't)

It seems like #17198 only addresses edit-post-header-toolbar__left.

[iandunn]

My use case is that I'd like to add a new button to the edit-post-header__settings

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's hard to communicate what the button does in an icon
• The icon won't be directly next to the Update button, which is the most logical place for it
• An entire sidebar just for a button feels like overkill
• The user has to click 3 times to perform the action, instead of once (open sidebar, press button, then press gear icon to restore the normal UI)
• It'd be hidden on mobile screens

[iandunn]

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?

[UranymusDev]

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