Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Block Management: Add the possibility to hide/show blocks from the inserter #14139
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
Let's try to explore integrating it (or something similar). Important notes:
For reference here is what you have in CoBlocks now, props @richtabor for this work:
A few points I would raise:
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).
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 seems like it could be the wrong approach, as it puts the onus on users to manage blocks, instead of WordPress working for them.
 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.)
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.