Block Management: Add the possibility to hide/show blocks from the inserter

[youknowriad]

Previously #4573

There has been a lot of feedback recently suggesting the need for a solution to "manage" the available blocks in the editor. Installing block plugins often brings a dozen of blocks while in reality the user only needs one or two of them.

After trying some existing solutions Gutenberg Manager, Cloud Blocks, Co Blocks... It seems that CoBlocks approach is the one that matches the Gutenberg design and development guidelines the most.

Let's try to explore integrating it (or something similar). Important notes:

• UI close to the editor
• It should hide and not disable blocks (disabling can harm the experience if used previously...)
• Hiding per category and block works for me but would love insights from designers
• The code should match design, dev and a11y guidelines.

[karmatosed]

For reference here is what you have in CoBlocks now, props @richtabor for this work:

A few points I would raise:

• How can the modal look more like the block picker itself? Does it need to be so large and different?
• Feedback/ awareness of disabling/enabling per block could be clearer. It's hard to know about that interaction.
• Moving to options makes sense.

[mapk]

Really nice work on this, @richtabor!

I like the use of the modal as it's keeping inline with similar interaction patterns from the "Tools & Options" screen. I'd agree that we might be able to make it look closer to the Block Inserter, and not be so wide. I've mocked something up to help relate what I'm saying.

How to disable/enable individual blocks needs some more iteration. There's not a lot of user feedback happening and it's not clear exactly how to proceed once the modal opens up.

I do love that if a block is in use, when clicking "Disable all," that particular block doesn't disable. Smart.

And while the wording isn't quite right, I can imagine the Tools & Options sidebar to eventually include a "Block Management" section. This could include the Block Manager, Resusable block management, and even the Block DIrectory (when we get there).

[samuelsidler]

Thinking aloud: I wonder if it makes sense to add in a full interface for this, versus Gutenberg being "smart" about which blocks are shown and when. For example, Gutenberg could expose which blocks are part of which plugins, even notifying the user when they attempt to disable a plugin, if they've used blocks from it. Gutenberg could also automatically disable blocks that haven't been used, but still expose them if searched for and note that they're "disabled". I'm sure there are other approaches that could improve both discoverability of blocks and the overhead of dozens of blocks installed.

Adding an interface for block management, especially one that's inherently complex[1] seems like it could be the wrong approach, as it puts the onus on users to manage blocks, instead of WordPress working for them.

[1] If a typical user has a dozen or so plugins installed and each of them has 1-10 blocks, there's a lot to sift through to determine what's in use, what's not, what's the "right" block for them, etc. Do we have a sense of the average number of plugins installed and the current number of blocks per plugin? Is that data that can be gathered to make a more informed decision? (Noting, of course, that blocks will only get more not less popular.)

[aduth]

Pull request at #14224

[mapk]

I wonder if it makes sense to add in a full interface for this, versus Gutenberg being "smart" about which blocks are shown and when.

Hey @samuelsidler! I didn't want to leave your comment unaddressed. Your idea aligns with where AI is taking software interfaces in the future. I love it.

Right now we're hoping to get something like this in WP 5.2, and building an interface based on a modal system we already have in place shouldn't be too overwhelming. In fact, it looks like the scope of this might lighten up dramatically. Take a look at #14224 (comment) for further information.

[phpbits]

@youknowriad @aduth Would you mind letting me know where are you storing the data for active and inactive blocks? I am CoBlocks co-founder and we are planning to deprecate Block Manager but migrate them smoothly so users don't have to redo the disabling of blocks. Thanks!

[aduth]

Hi @phpbits , thanks for reaching out. From the implementation in #14224, the "hidden" block types are stored in a (currently client-side-only) preferences value in the core/edit-post store, as an array of the slugs of each block which should be hidden from the inserter.

Example:

wp.data.select( 'core/edit-post' ).getPreference( 'hiddenBlockTypes' );
// ["core/image"]

Similarly, you can add new values (your transitioning values) using hideBlockTypes:

wp.data.dispatch( 'core/edit-post' ).hideBlockTypes( [ 'core/heading', 'core/list' ] );

The result is that the preference is updated to a union of the existing preference value and the provided values.

wp.data.select( 'core/edit-post' ).getPreference( 'hiddenBlockTypes' );
// ["core/image", "core/heading", "core/list"]

• https://wordpress.org/gutenberg/handbook/designers-developers/developers/data/data-core-edit-post/#hideblocktypes
• https://wordpress.org/gutenberg/handbook/designers-developers/developers/data/data-core-edit-post/#showblocktypes

[phpbits]

@aduth Thanks a lot for creating the function :) This will make the migration a lot easier! Hoping I don't encounter any conflicts. If in any case I find any, I hope it's okay to let you know ;) Thanks again and great work on the Block Management 💯