Add a way to programmatically remove editor panels from UI

[gziolo]

Description

Closes #6225.
Related to #6533.

This PR addressed the following requests:

Is there anything equivalent for Gutenberg, i.e. to remove a panel from the settings on the right side?

From @ecobux:

is there any solution how to remove the panel of the post tags?

How has this been tested?

Execute the following code in the JS console to remove one of the panels and ensure it is not present in the sidebar and Options modal (you can access it from More Menu):

wp.data.dispatch( 'core/edit-post').removeEditorPanel( 'taxonomy-panel-category' ) ;
wp.data.dispatch( 'core/edit-post').removeEditorPanel( 'taxonomy-panel-post_tag' );
wp.data.dispatch( 'core/edit-post').removeEditorPanel( 'featured-image' );
wp.data.dispatch( 'core/edit-post').removeEditorPanel( 'post-excerpt' );
wp.data.dispatch( 'core/edit-post').removeEditorPanel( 'discussion-panel' );

Note that you can't remove Post & Visibility panel. The following (despite being valid) won't be reflected in the UI:

wp.data.dispatch( 'core/edit-post').removeEditorPanel( 'post-status' );

Screenshots

With all available panels completely removed:

With a few panels completely removed:

Known issues

@noisysocks I would appreciate your help here:

When you remove all panels, the section title is still there. Is there an easy way to hide it, too? I know I could use CSS but I would prefer to do it properly :)

Another thing I'm not happy about is that this setting persists. I think this could cause some issues when someone uninstalls a plugin which would use this feature as marked panels would remain removed. Should we move this outside of the persisted state?

Types of changes

New feature (non-breaking change which adds functionality for backwars compatibility).

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

[tofumatt]

Should we move this outside of the persisted state?

I think yes, because: as you say—these panels being removed after a plugin that does so is uninstalled is very weird UX.

Really, they should be persisted changes if they were user-made changes (hiding the tag panel, etc.) but they shouldn't be persisted if a plugin made them (hiding the default tag panel to show a custom one).

Also: your testing instructions read like they'd make good E2E tests and this seems an important part of the UI we're modifying, so I think writing some E2E tests to confirm things work and revert as intended would be wise here.

[noisysocks]

It feels weird to me that we have isEditorPanelEnabled() / toggleEditorPanelEnabled() and isEditorPanelRemoved() / removeEditorPanel(). Could we consolidate these APIs?

When you remove all panels, the section title is still there. Is there an easy way to hide it, too? I know I could use CSS but I would prefer to do it properly :)

It's a shame that there's no way to ask React if props.children will render as empty...

I had a similar problem with <MetaBoxSection> and ending up having to add logic to the section rather than keeping it in each option.

I'm struggling to think of a nice way around this. Perhaps need to bite the bullet and move away from having <OptionsModal> implemented with nested components. Instead, we can have a function generate the options data which a dumb <OptionModal> component then renders a UI for.

Another thing I'm not happy about is that this setting persists. I think this could cause some issues when someone uninstalls a plugin which would use this feature as marked panels would remain removed. Should we move this outside of the persisted state?

Not persisting it makes sense to me.

[gziolo]

Also: your testing instructions read like they'd make good E2E tests and this seems an important part of the UI we're modifying, so I think writing some E2E tests to confirm things work and revert as intended would be wise here.

@tofumatt, I added e2e test with 03e99bb.

I think yes, because: as you say—these panels being removed after a plugin that does so is uninstalled is very weird UX.

Not persisting it makes sense to me.

Now I that have e2e and unit tests in place, I can refactor store to avoid persistence layer. It looks like there is common agreement that it's wrong :)

It feels weird to me that we have isEditorPanelEnabled() / toggleEditorPanelEnabled() and isEditorPanelRemoved() / removeEditorPanel(). Could we consolidate these APIs?

Agreed on this one, however, I didn't find a better way to distinguish between user's interaction which hides the panel and site owners willingness to never offer this panel to their users. If you have any ideas I'm happy to update PR.

I'm struggling to think of a nice way around this. Perhaps need to bite the bullet and move away from having <OptionsModal> implemented with nested components. Instead, we can have a function generate the options data which a dumb <OptionModal> component then renders a UI for.

Yeah, it should be a follow-up issue as it might be a lot of work for an extremely rare case.

[tofumatt]

I agree with @noisysocks that it would be nice to consolidate these selectors or make them more consistently named, but I'm a bit short on ideas for it at the moment. They are expressing different ideas though; maybe it's fine 🤷‍♂️

At any rate, the tests and the code look good to me.

[gziolo]

@tofumatt one more commit before we proceed: d1c9038 :)

This moves removedPanels out of preferences which are persisted by default.

Update: one more fix which deletes dead code: 54fce2e.

[tofumatt]

Works for me!

[swissspidy]

Is there any way to add panels? And no, I don't want to add an old-school meta box or a separate plugin sidebar.

[gziolo]

You can always register your own sidebar with as many panels as you want. See:
https://github.com/WordPress/gutenberg/tree/master/packages/plugins#plugins-api
https://github.com/WordPress/gutenberg/tree/master/packages/edit-post/src#pluginsidebar

There is no way to add a panel to the Document Settings sidebar.

[genseirin]

@gziolo Thank you for that! I need exactly

wp.data.dispatch( 'core/edit-post').removeEditorPanel( 'taxonomy-panel-post_tag' );

But how can I apply it when none of my blocks are in use? It should be independent from the blocks.

[genseirin]

Never mind, I found a way. 😄

[manuelmeister]

@gziolo are you planning to add a way to add panels to the Document Settings sidebar?

[gziolo]

@manuelmeister - it is still under consideration. It all depends how Phase 2 of Gutenberg evolves and what is going the full page editing look like. It will have the biggest impact on how we tackle this issue. At the moment, there is this consideration that adding more sections might conflict with the direction phase 2 might take. In particular, we don’t want UI to be locked down to the single sidebar area used by the majority plugins. @youknowriad, is there antyhing I missed?

[helgatheviking]

@gziolo If it is not yet possible to add a panel to the Document Settings sidebar, is it possible to "override" how a panel renders?

[gziolo]

@gziolo If it is not yet possible to add a panel to the Document Settings sidebar, is it possible to "override" how a panel renders?

It's not possible to add your own panel to the Document Settings as of today, however you can create your own sidebar:
https://github.com/WordPress/gutenberg/blob/master/docs/designers-developers/developers/tutorials/sidebar-tutorial/plugin-sidebar-0.md

Some panel can be overridden as explained in:

• https://github.com/WordPress/gutenberg/tree/master/packages/editor/src/components/post-taxonomies#posttaxonomies
• https://github.com/WordPress/gutenberg/tree/master/packages/editor/src/components/post-featured-image#postfeaturedimage

@chrisvanpatten, @mkaz or @nosolosw - do you know if we have those examples grouped somewhere?

[oandregal]

@gziolo to the best of my knowledge we don't have any tutorials about this and don't surface editor's components in the handbook either. Not sure if there's a specific reason for that, but it'd be great to do it somewhere.

[oandregal]

Also worth noting that the editor is one of the few packages that doesn't have autogenerated API-docs within its README. If we did that, it'd end up in the package section within the handbook. Although doable, my concern is that it'd be such big a file I worry if it'd became unusable.

A different approach we could take to improve docs is to group things together: using docgen we could generate a section containing all components from @wordpres/components, @wordpress/editor, @wordpress/edit-post, etc. Also worth it for grouping actions/selectors/etc from different stores. It's not something that's implemented but we could explore this idea.

[helgatheviking]

@gziolo The taxonomies link is very helpful. I have been able to use the example to add a random component there, but the existing term checklist HierarchicalTermSelector doesn't seem to be a Component that I can access/extend? Is that correct?

I have a plugin that used to convert switch taxonomy checklists to radio buttons.... effectively limiting the selection to a single term. So I'm looking for a way to use all the parts of the hierarchical checklist, but switch input from a checkbox to a radio.

[marbaque]

@gziolo Is there an implemented example of this solution? I tried to enqueue this javascript only in edit.php by creating a plugin, but didn't work.

[gziolo]

Is there an implemented example of this solution? I tried to enqueue this javascript only in edit.php by creating a plugin, but didn't work.

There is a corresponding e2e test which covers it:

gutenberg/packages/e2e-tests/specs/sidebar.test.js

Lines 108 to 134 in 6d3269e

	it( 'should be possible to programmatically remove Document Settings panels', async () => {
	await createNewPost();
	await openDocumentSettingsSidebar();
	expect( await findSidebarPanelWithTitle( 'Categories' ) ).toBeDefined();
	expect( await findSidebarPanelWithTitle( 'Tags' ) ).toBeDefined();
	expect( await findSidebarPanelWithTitle( 'Featured Image' ) ).toBeDefined();
	expect( await findSidebarPanelWithTitle( 'Excerpt' ) ).toBeDefined();
	expect( await findSidebarPanelWithTitle( 'Discussion' ) ).toBeDefined();
	await page.evaluate( () => {
	const { removeEditorPanel } = wp.data.dispatch( 'core/edit-post' );
	removeEditorPanel( 'taxonomy-panel-category' );
	removeEditorPanel( 'taxonomy-panel-post_tag' );
	removeEditorPanel( 'featured-image' );
	removeEditorPanel( 'post-excerpt' );
	removeEditorPanel( 'discussion-panel' );
	} );
	expect( await findSidebarPanelWithTitle( 'Categories' ) ).toBeUndefined();
	expect( await findSidebarPanelWithTitle( 'Tags' ) ).toBeUndefined();
	expect( await findSidebarPanelWithTitle( 'Featured Image' ) ).toBeUndefined();
	expect( await findSidebarPanelWithTitle( 'Excerpt' ) ).toBeUndefined();
	expect( await findSidebarPanelWithTitle( 'Discussion' ) ).toBeUndefined();
	} );

You need to ensure that your plugin's script depends on wp-edit-post.

[soderlind]

@gziolo Works nice, tested using https://wordpress.stackexchange.com/a/339437/14546, but ..
How do I hide/remove content inside Sidebar Block? (I know that I can hide some using add_theme_support()).

Eg.:

• When a gallery is created, I don't want the user to be able to change the number of columns, etc
• I want to remoce the Advanced option (at the bottom of Sidebar Block)

[gziolo]

How do I hide/remove content inside Sidebar Block? (I know that I can hide some using add_theme_support()).

There is no way for doing it at the moment, we are discussing some possible ways of tackling it in #15450. There is also a related and more detailed issue where the same feature was requested: #6023.

[Pakkendu]

Note that you can't remove Post & Visibility panel. The following (despite being valid) won't be reflected in the UI:

wp.data.dispatch( 'core/edit-post').removeEditorPanel( 'post-status' );

For a project of mine, the "pending review" is not needed and possibly bad for learning curve. Since removing 'Post & Visibility' is not working, is there another way to disable this "pending review" checkbox?