Allow for core block Inspector Controls to be extended and removed

[paulwilde]

For all client websites that I build I strip the WordPress admin down to the bare minimum as to reduce the burden and learning curve for my clients. This includes things like removing the Posts menu item if posts are not used on the site, and every meta box which aren't being used.

One big issue I'm struggling with Gutenberg at the moment in terms of extensibility, is that there's a bunch of inspector controls which I don't need, thus increasing said burden. A good example of this is the core/paragraph block, as that has a bunch of options allowing you to recreate a Geocities website where you can set inline background & font colours and whacky text sizes.

As there is currently no API or filter to remove the controls, I've had to resort to a bunch of sophistically CSS to simply display: none the Text Settings panel and recreate the options I want.

An idea for an API would be to wrap each control which gets rendered in the Text Settings panel inside a keyed array, where the value is the control component which gets rendered.

Using core/gallery as an example, due to it only having 3 controls currently, something like this:

let controls = {
    setColumnsNumber: <RangeControl
        label={ __( 'Columns' ) }
        value={ columns }
        onChange={ this.setColumnsNumber }
        min={ 1 }
        max={ Math.min( MAX_COLUMNS, images.length ) }
    />,
    imageCrop: <ToggleControl
        label={ __( 'Crop Images' ) }
        checked={ !! imageCrop }
        onChange={ this.toggleImageCrop }
    />,
    linkTo: <SelectControl
        label={ __( 'Link to' ) }
        value={ linkTo }
        onChange={ this.setLinkTo }
        options={ linkOptions }
    />,
};
controls = applyFilters( 'blocks.inspectorControls', controls, this );

Then with such a pattern in place, one can easily remove controls as they desire. Assuming lodash is being used, this filter would remove the setColumnsNumber and imageCrop controls:

function removeGalleryControls( controls, block ) {
    if ( 'core/gallery' == block.props.name ) {
        return omit( controls, [ 'setColumnsNumber', 'imageCrop' ] );
    }
    return controls;
}
addFilter( 'blocks.inspectorControls', 'remove-gallery-controls', removeGalleryControls );

This filter would update the Columns control by changing the maximum range, and updating its label:

function replaceGalleryControl( controls, block ) {
    if ( 'core/gallery' == block.props.name ) {
        const { columns } = block.props.attributes
        
        controls.setColumnsNumber = <RangeControl
            label={ __( 'New Label!' ) }
            value={ columns }
            onChange={ block.setColumnsNumber }
            min={ 1 }
            max={ 3 }
        />;
    }
    return controls;
}
addFilter( 'blocks.inspectorControls', 'replace-gallery-control', replaceGalleryControl ); 

And obviously reordering the controls along with adding additional ones should be quite evident at this point. Also it's easier to globally add controls to more than 1 block at a time which is an added advantage.

It's possible that there might be a cleaner or more React-like approach which allows for such extensibility, however I do believe it's quite a critical pain point prior to Gutenberg shipping.

[noisysocks]

cc. @gziolo

[gziolo]

Related comment from #5995:

Although I like the changes, this has had an impact on my implementation where I've been adding additional controls to core blocks.

As an example with the 'Advanced' Settings disabled (Custom CSS and Anchors), I have added 3 additional controls to the Heading Settings. The last 3 at the bottom:

However, when the panel is closed, these additional settings are no longer contained within the same panel:

I don't want to be limited to where I need to create a separate expandable panel for very basic additional settings such as text colour as it adds more weight to the UI. I'd want them to live in the same main 'Heading Settings' panel.

As there is currently no documentation on how controls can be added to existing blocks I used the implementation that the Custom CSS and Anchors uses in order to learn on how to add these additional controls. Maybe its possible to target the controls to be rendered at the bottom of the 'Heading Text' component, although I couldn't figure it out.

For clarify sake, here is what I'm doing to add new controls:

function onUpdate( BlockEdit ) {
    const WrappedBlockEdit = ( props ) => {
        if ( 'core/heading' !== props.name ) {
            return <BlockEdit { ...props } />
        }

        const { attributes, setAttributes, isSelected } = props
        
        return [
            <BlockEdit { ...props } />,
            isSelected && <InspectorControls key="inspector">
                <ToggleControl
                    label={ __( 'Custom Control' ) }
                    checked={ !! attributes.customControl }
                    onChange={ onChangeEvent }
                />
            </InspectorControls>,
        ]
    }
    return WrappedBlockEdit
}
addFilter( 'blocks.BlockEdit', 'custom/heading/update', onUpdate )

[jasmussen]

This use case seems perfectly valid as a point of extensibility going both ways.

Before starting work on addressing the specific use case, it seems worth looking at inspector controls as they are today, as they are a little bit all over the place (yes, we've had to work fast!):

• Heading has panels for all controls
• Button does not have a panel for the first set of controls
• Paragraph starts with most panels collapsed, but not the alignment one
• the lack of borders between panels, like in the Document sidebar, makes it a bit hard to see where one panel ends and another panel begins
• state of panel isn't saved between sessions or users (separate point you made, @paulwilde)

It seems like the first step then, is to add consistency between all current inspector controls, just as a stepping stone to more advanced extensibility. Without patterns, any extensibility we build will be a nightmare to work with.

Such a ToDo could be to add borders between panels, to match the Document sidebar:

(not with the double border as shown above, that's just a bad inspector mockup)

Decide a pattern for which panels are open by default. For example we could decide that only the topmost panel is open, all subsequent ones are closed. A future PR that stores this state on a user basis would then ameliorate any commonly used settings, while still keeping a strong default pattern.

Decide, perhaps, that no settings can be added to the sidebar, without being part of a panel. I.e. Button block would need some work.

---

In the end we'd have something far more manageable — every inspector would look like this:

[block description]
---
Block Settings ▼
... various block settings ...
---
Other Settings ▶
---
Advanced Settings ▶

The benefit of doing this legwork, aside from the consistency it would bring, is that it would help surface answers to how to best extend this.

Maybe we'll learn it is sufficient to be able to unregister/remove a panel and/or add your own.

Or maybe we'll learn that you do in fact need to be able to extend every panel, in addition to removing panels or adding your own.

[gziolo]

@jasmussen @paulwilde thanks for sharing your feedback. I think that the most important part is to decide first how we want to have the Inspector Controls designed and structure before we come up with any further refinements. We need to make sure that we have consistent look and feel for those controls before we allow any advanced detailed manipulations.

The biggest challenge I see here is to decide where we draw the line between modifying the existing block and creating your own instance of the same block which has some options removed.

Also the proposed API for modifying the list of controls could be as simple as:

supports: {
    allowedInspectorControls: [ 'align', 'fontSize' ],
}

where allowedInspectorControls would list all enabled controls. There is still questions if it should be control based or control groups based. That's why we need to finalize how it should be designed first.

[jasmussen]

That's a great way to frame it, and pseudo code API example. It can also help frame the decision.

Hypothetical: let's say there's a panel called Alignment, or Layout, that came with a core block. Let's say a plugin wanted to extend that panel, and provide additional alignment or layout related options. If the API was control groups based, would the plugin be able to unregister, copy the initial one, and then recreate the panel with additional options?

[MikeB8s]

I think that this discussion might also apply to custom taxonomy blocks in the side panel. For instance, a plugin should be able to disable/hide the taxonomy Parent form (issue #6057)

[jasonbahl]

Without the ability to filter controls right now, we’re replacing just about every core block with our own custom versions of blocks so we can control the experience better. I think the filterability of the inspector fields is very critical to consider Gutenberg ready to ship.

I believe this should be considered as related to #2751, as core inspector controls should be defined in the server side registry for blocks, so that all clients(CLI, Gutenberg, REST, WPGraphQL, iOS/Android) can have appropriate knowledge of what controls exist for interaction with any given block.

Gutenberg Fields Middleware (https://github.com/rtCamp/gutenberg-fields-middleware) is a great project worth looking at to show how Inspector controls can be registered (and thus filtered/deregistered) all from the server block registry.

[chrisvanpatten]

We're in a similar position — we want to remove support for font sizes and drop caps in the paragraph block, and are likely going to need to resort to a CSS display: none hack since we want to avoid replacing core blocks.

[MikeB8s]

At least for the case of custom taxonomies in the Gutenberg plugin, ids have been removed from the side panel controls, which hinders even using CSS to hide controls.

[jasonbahl]

Ya, I’d be curious to see a CSS solution to hide specific controls based on the current CSS output. 🤔

[chrisvanpatten]

For text size, it's quite easy. That inspector panel can be targeted with .components-panel__body.blocks-font-size. Luckily for me, we don't need to hide anything else on this particular project.