Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
imanish003 opened this issue Feb 1, 2023 · 5 comments
Open

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

imanish003 opened this issue Feb 1, 2023 · 5 comments
Labels
[Feature] Block API API that allows to express the block paradigm. [Feature] Extensibility The ability to extend blocks or the editing experience Needs Dev Ready for, and needs developer efforts [Type] Enhancement A suggestion for improvement.

Comments

@imanish003
Copy link
Contributor

imanish003 commented Feb 1, 2023


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 #47641 (comment).

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.

@imanish003 imanish003 changed the title Way to remove a specific toolbar button from BlockControls Way to remove a specific toolbar button from Block Toolbar Feb 1, 2023
@imanish003 imanish003 changed the title Way to remove a specific toolbar button from Block Toolbar Provide a way to remove a specific toolbar button from Block Toolbar Feb 1, 2023
@kathrynwp kathrynwp added [Type] Enhancement A suggestion for improvement. [Block] Buttons Affects the Buttons Block [Package] Block editor /packages/block-editor labels Feb 1, 2023
@gziolo gziolo added [Feature] Block API API that allows to express the block paradigm. and removed [Block] Buttons Affects the Buttons Block labels Feb 3, 2023
@gziolo gziolo added the [Feature] Extensibility The ability to extend blocks or the editing experience label Feb 20, 2023
@gziolo gziolo changed the title Provide a way to remove a specific toolbar button from Block Toolbar Block Editor: Provide a way to remove a specific toolbar button from Block Toolbar Feb 20, 2023
@gziolo gziolo mentioned this issue Feb 20, 2023
69 tasks
@gziolo gziolo added the Needs Dev Ready for, and needs developer efforts label Feb 27, 2023
@gziolo
Copy link
Member

gziolo commented Apr 12, 2023

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 gziolo changed the title Block Editor: Provide a way to remove a specific toolbar button from Block Toolbar Block Editor: Provide a way to customize items in Block Toolbar Oct 3, 2023
@gziolo gziolo added Needs Dev Ready for, and needs developer efforts and removed Needs Dev Ready for, and needs developer efforts [Package] Block editor /packages/block-editor labels Oct 4, 2023
@gziolo
Copy link
Member

gziolo commented Oct 4, 2023

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 #33891 for Inspector Controls.

@imanish003
Copy link
Contributor Author

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
Copy link

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.

@retrofox
Copy link
Contributor

Could we play by binding the url attribute?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Block API API that allows to express the block paradigm. [Feature] Extensibility The ability to extend blocks or the editing experience Needs Dev Ready for, and needs developer efforts [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

5 participants