Open imanish003 opened 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.
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.
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 🙌🏻.
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.
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 needlink
button in toolbar as shown in screenshot below: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:
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:
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:
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.