Gutenberg: After unpinning a PluginSidebar, there's no way to get it back

[mboynes]

If a user accidentally or deliberately unpins a plugin sidebar (PluginSidebar component) that doesn't also add a "More menu item" (PluginSidebarMoreMenuItem component), that sidebar appears to be lost for that user. In addition, there doesn't appear to be a way to disable the ability to unpin a sidebar.

To Reproduce

1. Create a plugin with a PluginSidebar component
2. Display that plugin sidebar and then unpin it
3. You can no longer get back to that sidebar

Expected behavior

Either,

1. Gutenberg provides a separate UI to view/open unpinned sidebars, e.g. in the "Options" modal
2. "Unpinning" is an opt-in feature for PluginSidebar, so developers can opt to allow that if they're also adding another way to get to that sidebar, e.g. via PluginSidebarMoreMenuItem

Duplicates #14211, but I have no way to reopen that so I'm submitting it anew.

[swissspidy]

Can we make it mandatory to use PluginSidebarMoreMenuItem or at least educate developers through documentation?

[mboynes]

While developer education could help, I think this is something Gutenberg should “just do” to provide a better developer experience.

The pinning feature seems half-developed to me as-is. Since the editor is providing the “unpin” feature, I think the right approach is for the editor to also provide a list of unpinned items so users can see and open them.

[gziolo]

@jasmussen, any thoughts on how to solve it? Enforcing the menu item would be a breaking change at this point. What if we offer a prop for the sidebar component which would add the menu item behind the scenes. So based on this example from e2e test:
https://github.com/WordPress/gutenberg/blob/master/packages/e2e-tests/plugins/plugins-api/sidebar.js#L85-L102

we could have:

<PluginSidebar
    name="title-sidebar"
    title={ __( 'Sidebar title plugin' ) }
    moreMenu
>
    <SidebarContentsWithDataHandling />
</PluginSidebar>

[jasmussen]

any thoughts on how to solve it? Enforcing the menu item would be a breaking change at this point.

Why is this a breaking change?

I do apologize for not having followed the intricacies of this along the way, but it was my impression that it _was_ the case that any plugin that registered a sidebar must also have a menu item, this was a key part of the initial design and more or less the whole reason for plugins also having a menu item in the first place.

In other words, I feel like the correct solution is to _enforce that_. A plugin that registers a sidebar must also have a menu item.

The question then becomes: how can we enforce that? Is there a creative way we can do this without this being a breaking change? Can we smartly detect that a sidebar is present, and create the menu item for the plugin?

Inversely, a plugin that registers a sidebar, should _not_ be able to _not_ have a menu item. The two should be strongly linked.

[gziolo]

Inversely, a plugin that registers a sidebar, should not be able to not have a menu item. The two should be strongly linked.

We didn't make this assumption initially so you can have your sidebar without a menu item. Why we can enforce it technically because there are no technical limitations to do so, the issue is that it's quite complicated to detect whether such menu item was already defined by the plugin. In other words, if a plugin defines the menu item and we enforce it from the sidebar, you could have the case where the menu item duplicates. I would rather avoid a situation and come up with a solution where it's easier to enable the menu item when you use the sidebar.

[jasmussen]

Given the situation, we should definitely explore creative solutions. But I really do feel like the _right_ solution is that every sidebar plugin should have a menu item, so I would encourage brainstorms that move in that direction.

Plan C (let's think of better options before going here) could be to create a new section in the menu called "Closed Sidebars", and every sidebar that gets closed shows up here as a menu item. Sidebars that already register their own menu item could either then:

• not show up there, if we could do that automatically
• opt out of showing up there in a new plugin update, and show up twice until they do

[mboynes]

An alternate plan C, which might be easier, could be to make "pinning" an opt-in feature. e.g. <PluginSidebar pinnable />.

[gziolo]

I will think about it and get back with some proposal after WordPress 5.2 RC. The more I think about it, the more viable your proposals are. We already have isPinnable prop which can be used to disable pinning:
https://github.com/WordPress/gutenberg/blob/master/packages/edit-post/src/components/sidebar/plugin-sidebar/index.js#L24

We could reuse it to reason about menu items. The biggest challenge is how to detect whether there is another menu item present for the existing plugins. I'm positive we can tweak codebase to make it possible to filter out duplicates :)

[nosolosw]

Wanted to note here that the Sidebar tutorial might need tweaking if we change the behavior (see https://github.com/WordPress/gutenberg/pull/15638).

[conanliuhuan]

I have the same problem