WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.48k stars 4.18k forks source link

Block Editor: Provide a way to customize items in Block Toolbar #47641

Open imanish003 opened 1 year ago

imanish003 commented 1 year ago

What problem does this address?

There is no way to remove a toolbar item from Block Toolbar.

Note: It isn't limited to block variations only, but it's a general concern as explained in https://github.com/WordPress/gutenberg/issues/47641#issuecomment-1505800659.

What am I trying to achieve?

In WooCommerce Blocks, I am implementing a variation of core/buttons but I don't need link button in toolbar as shown in screenshot below: Screenshot 2023-02-01 at 2 57 43 PM

The variation will be for Add to cart button. We want to remove the “link” toolbar item for the button so that merchants aren’t confused by that (since the link is provided dynamically during render).

Why solve this problem?

While creating variations of GB blocks, I believe it's a common scenario when a developer might want to hide some of the toolbar buttons. By allowing developers to remove toolbar items, we can make block variations more powerful & flexible.

For now, we have a way to add new toolbar items using BlockControls, but there is no way to remove existing controls.

Why not hide using CSS?

One way to hide toolbar button is by using DOM API. For example:

const linkElement: HTMLElement | null =
    document.querySelector(
        '.edit-post-visual-editor button[name="link"]'
    );
if ( linkElement ) linkElement.style.display = 'none';

But as you can see, we have to depend on a CSS selector with a class name. AFAIK class names can change anytime in future & therefore, this code might break in future.

What is your proposed solution?

Some of the solution I can think of are:

Solution 1

One way could be to provide a way to hide toolbar buttons by name while registering variation using registerBlockVariation method.

For example:

wp.blocks.registerBlockVariation( 'core/buttons', {
  ...,
  hideControls: [ 'link' ],
} );

hideControls may accept list of controls which should be hidden for the variation.

Solution 2

One more way could be to let developer decide if a control should be visible or not using a callback function provided in registerBlockVariation.

For example:

wp.blocks.registerBlockVariation( 'core/buttons', {
  ...,
  hideControl: (control) => {
    if(control.name === 'link'){
      return true;
    }
    return false;
  },
} );

hideControl will be called before showing a control on UI. This will be even more flexible because developer can compute here if a control be should hidden or not.

Solution 3

One more solution could be to provide a filter hook in which we can decide if toolbar should be visible or not.

gziolo commented 1 year ago

In #49398, @Alex-HdD proposes customizing Block Toolbar using supports field in block settings.

Customization of Block Toolbar

We want to show users only specific block customization options but it is currently difficult to customize the Block Toolbar and hide options without using css or other workarounds.

What is your proposed solution?

Every toolbar button can be activated or deactivated with the supports field in the block's settings. A boolean may be used to show or hide toolbar options. Also imaginable would be to restrict options for particular user groups.

gziolo commented 1 year ago

This is one of the items that we plan to tackle as part of the Block Library project from Phase 3: Collaboration roadmap. In particular, this functionality was covered by @mtias in the following section:

It also means introducing more robust permission handling across the various capabilities (block registration, locking, etc) so administrators can define what blocks are available for different user roles (or even what capabilities of individual blocks are to be exposed). The fact that theme.json files are inherently composable should allow for more granular handlings of capabilities in a systematic way. For example, consider a fictional author.theme.json that sets, disables, and controls what tools and settings are available for authors over the root config file.

There is also a complementary issue https://github.com/WordPress/gutenberg/issues/33891 for Inspector Controls.

imanish003 commented 1 year ago

Hey Greg 👋🏻

Thanks for sharing the future plans. I'm not entirely sure if what you shared will address this issue, as the quoted message seems to focus more on permissions and blocks rather than block variations. However, I'm glad to hear that there are plans to add the capability to remove items from the Toolbar and inspector controls 🙌🏻.

andreawetzel commented 3 months ago

This feature will be helpful for cases when a custom block uses InnerBlocks with core blocks and want to limit allowed formats in some cases.

For example, we may want to allow formatting such as text highlighting for body copy, but remove that option from the block toolbar for inner blocks allowed within a custom accordion block.