Extensibility: Add possibility to disable document settings panels registered by plugins

[gziolo]

Description

Follow up for #13361. It addresses my own comment #13361 (review):

There is also a separate issue which we need to consider in the follow-up - how to expose those registered panels in the Options modal:

This PR introduces internal SlotFill pair to offer a way for users to disable/enable registered Document settings panels by plugins.

How has this been tested?

Register a custom document setting panel in the sidebar with the following snippet:

( function() {
	var el = wp.element.createElement;
	var __ = wp.i18n.__;
	var registerPlugin = wp.plugins.registerPlugin;
	var PluginDocumentSettingPanel = wp.editPost.PluginDocumentSettingPanel;

	function MyDocumentSettingPlugin() {
		return el(
			PluginDocumentSettingPanel,
			{
				className: 'my-document-setting-plugin',
				title: 'My Custom Panel 1'
			},
			__( 'My Document Setting Panel 1' )
		);
	}

	registerPlugin( 'my-document-setting-plugin-1', {
		render: MyDocumentSettingPlugin
	} );
} )();

In my tests, I registered multiple panels to ensure that it's possible to enable/disable them and everything is rendered in the same order in both the sidebar for Document setting and in the Options modal.

Screenshots

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[jorgefilipecosta]

This works well in my tests 👍
I noticed that if the plugin is not currently showing the panel no option to hide it appears. I imagine some plugins may only show the panel in rare circumstances, so for the user to disable the panel, it first needs to create a case where it appears. Would it make sense to allow plugins to explicitly add an option to disable their panel even if it is not being shown right now?
Another related question: If there is a plugin panel that is currently being drawn but not shows because the user disabled it, would it make sense to show a small UI feedback in the document settings indicating hidden panels exist?

[gziolo]

I noticed that if the plugin is not currently showing the panel no option to hide it appears. I imagine some plugins may only show the panel in rare circumstances, so for the user to disable the panel, it first needs to create a case where it appears. Would it make sense to allow plugins to explicitly add an option to disable their panel even if it is not being shown right now?

Can you clarify what needs to happen to have that? Do you mean having something like the following?:

{ showMyPanel && <PluginDocumentSettingPanel /> }

This would prevent the option to be visible in the modal, yes. Any ideas about how we could approach it, I can't think of any solution which works out of the box. Otherwise, this option will always be present in the modal as it's not guarded internally by any check.

Another related question: If there is a plugin panel that is currently being drawn but not shows because the user disabled it, would it make sense to show a small UI feedback in the document settings indicating hidden panels exist?

@mtias, @mapk or @jasmussen any thoughts about that? I guess we might cover it with the new tips if that makes sense. I'm not convinced we need it though.

[mtias]

I'm not convinced we need it though.

Agreed.

[mapk]

When hiding blocks in the Block Manager, we didn't plan how to communicate it outward, and it's definitely bit me in the butt a few times. It was a necessary exploration though. With this example, I agree that we don't need to notify the user of which panels are turned off... right now. It's something to watch as we introduce this though.

[jorgefilipecosta]

Can you clarify what needs to happen to have that? Do you mean having something like the following?:

{ showMyPanel && }

This would prevent the option to be visible in the modal, yes. Any ideas about how we could approach it, I can't think of any solution which works out of the box. Otherwise, this option will always be present in the modal as it's not guarded internally by any check.

One option would be to expose the fill that allows disabling a specific panel so if a plugin things it is a better UI to always have the option to disable the panel available the plugin could do it.

But on second thought, this just makes our API bigger while trying to solve a problem that we don't if it exists.

I think this PR is ready 👍

[gziolo]

But on second thought, this just makes our API bigger while trying to solve a problem that we don't if it exists.

In 99% of cases, we should offer a way to disable/enable the panel which nicely aligns with all panels included in core. So we can live with it :)

[noisysocks]

Should we add some docs for this? 😇

[gziolo]

Should we add some docs for this? 😇

What kind of docs would you like to see? This is all internal to the edit-post module.

[noisysocks]

Ah, apologies. I misread and thought EnablePluginDocumentSettingPanelOption was something that plugin developers had to include in their code.