Gutenberg: 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 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 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.