Introduce a UI for setting `allowedBlocks` in blocks that support it

[mtias]

Container blocks already support an allowedBlocks attribute in the markup to express what blocks can be inserted. This is a very cool feature that can allow site creators to provide highly usable flows without needing to create entirely custom blocks. It can be tedious to write by hand, though, so we could explore exposing UI for it in the Advanced panel. The interface should be similar to the block manager design.

Here's a prototype outlining an interface for managing allowed blocks. Essentially, we can use a secondary button with the label 'Manage':

And it opens up this modal providing the ability to search through the list and select with checkboxes.

• Searching (list filtration) works the same as in the preferences modal from the block manager.
• Order of blocks in the list is also the same.

✨ Mockup:

This can be way easier for users to recognize and easily scan the blocks they want to allow, and they're already used to this pattern (from the preference modal) so it's quite familiar.

Note: See also the discussion for an important added aspect of needing a way to differentiate between the state when all blocks are allowed, and when only a subset is. One suggestion is to add a subheading in the quick inserter, when only a subset is allowed.

✒️ And here's the figma file.

Props @seifeldinio for the design work.

[seifeldinio]

This sounds like a great enhancement! 😄

👉 The goal of this design is to improve the user experience of configuring allowed blocks within container blocks in the WordPress editor.

I explored two potential solutions for this.

Solution 1:

✨ Prototype for solution 1: https://www.figma.com/proto/KzSCVUfd5rrKxptxxZothF/Allowed-Blocks-Suggestion?page-id=1%3A3&node-id=1-655&viewport=2393%2C599%2C0.34&t=klfxYDS7aiERaQG6-1&scaling=scale-down&content-scaling=fixed&starting-point-node-id=1%3A655

✒️ Figma file with mockups and documentation: https://www.figma.com/design/KzSCVUfd5rrKxptxxZothF/Allowed-Blocks-Suggestion?node-id=0-1&t=RWXE2iWL4hfzSOj5-1

Screenshot:

Overview:

1. Users click the "Add" button to open a text input for their ability to search for a block alongside the block selection menu.
2. Block Selection Menu: A searchable list of available blocks appears, allowing users to select blocks they want to permit inside the container.
3. Selected Blocks Display: Chosen blocks are displayed within the "Allowed Blocks" section with options to remove them if necessary.

Note: The list can get very long, we can mitigate it by specifying a height for the dropdown and adding an overflow y set to scroll. That way we can scroll the list of suggestions. This relies more on recognition rather than recalling the block names.

Solution 2:

✨ Prototype for solution 2: https://www.figma.com/proto/kHVbgTTtuWHSbPbTuHeg4t/Allowed-Blocks-Suggestion-(Iteration-%232)?page-id=1%3A3&node-id=1-655&viewport=3662%2C662%2C0.54&t=lYfte1OTqFtR4kYc-1&scaling=scale-down&content-scaling=fixed&starting-point-node-id=1%3A655

✒️ Figma file with mockups and documentation: https://www.figma.com/design/kHVbgTTtuWHSbPbTuHeg4t/Allowed-Blocks-Suggestion-(Iteration-%232)?node-id=0-1&t=IRIQeVCinA8cbAWc-1

Screenshot:

Overview: Alternatively, specifying the allowed blocks using tags seems like a natural transition (since users had to specify it manually using markup). But potential usability issues here might be:

1. Relying too much on recall (which increases cognitive load).
2. A little hard to scan since we only have the label of the block, but we can solve this by adding an icon for the block for easy scanning.

With icons for easy scanning.

Without icons.

3. Input validation is crucial here to make it less error prone due to manual user input.

Thank you so much for your time reading and considering this! 😄

[jasmussen]

Nice work! The tags interface may benefit from the existing componentry, though we'd want you to only be able to choose from existing blocks. As far as icons, the main downside is that they were designed to be 24x24px. If we can fit those unscaled still, it can work well, but scaled down the stroke width changes.

[mtias]

Thanks for the explorations! I'd lean towards reusing the preferences modal from the block manager given there's quite a few complexities in the interactions and handles block categories already.

So click a button, open modal, select the blocks, click done:

[seifeldinio]

I like this approach, it also seems more efficient to reuse this modal!

⚡ Here's a new prototype (Iteration 3) for this approach: https://www.figma.com/proto/YQmyIgmGqEu4j3bzLverJI/Allowed-Blocks-Suggestion-(Iteration-%233)?page-id=94274%3A1696&node-id=94274-8153&viewport=415%2C377%2C0.3&t=1zZZ4E4kQT4R25VT-1&scaling=scale-down&content-scaling=fixed&starting-point-node-id=94274%3A8153

We can use a secondary button with the label 'Manage'

✨ Mockup:

And it opens up this modal providing the ability to search through the list and select with checkboxes.

• Searching (list filtration) works the same as in the preferences modal from the block manager.
• Order of blocks in the list is also the same.

✨ Mockup:

This can be way easier for users to recognize and easily scan the blocks they want to allow, and they're already used to this pattern (from the preference modal) so it's quite familiar.

✒️ And here's the figma file: https://www.figma.com/design/YQmyIgmGqEu4j3bzLverJI/Allowed-Blocks-Suggestion-(Iteration-%233)?node-id=0-1&t=ACGiDQBrmRYULDOh-1

[jasmussen]

Nice work, that looks good! I'll let others chime in with feedback if they have any, otherwise this sounds close to migrating to "Needs dev" territory. Thanks for contributing 👌

[jasmussen]

Following up on this one, given no pushback on the proposed approach, I've updated the original issue and added the "Needs Dev" label. Thank you and kudos to @seifeldinio for the work!

[mtias]

@jasmussen I think we need a way to communicate the status once certain blocks are allowed. From the mockup it seems the normal state (all blocks allowed) displays the same as a managed state (a few blocks allowed).

[jasmussen]

I think we need a way to communicate the status once certain blocks are allowed. From the mockup it seems the normal state (all blocks allowed) displays the same as a managed state (a few blocks allowed).

Here's a quick differentiation:

Essentially, when only a subset is allowed, we show a subheading—"Allowed blocks"—in the quick inserter.

[mtias]

@jasmussen this is not what I had in mind—the thing that is not clear is this element:

Once blocks are set I expect to see which ones are set without having to click "manage".

[jasmussen]

Ah thanks for chiming in. Something like this perhaps?

[jasmussen]

Updated the issue.

[jhmonroe]

@mtias @jasmussen having this look/work like the Preferences modal makes a lot of sense. The designs being created for the Block Bindings manager (#63018) should follow your lead as well. They are proposing a flyout —which isn't used anywhere else? —which wouldn't mimic the native modal experience and —which wouldn't allow for long scrolling the way a modal does if the list gets long. I linked to your design on their thread as well!

[jasmussen]

The flyout is used for color, for one:

It's also used in a slew of other places, especially ones where the canvas being in-view while you're configuring, has value. I think it can work for managing block bindings, by being light-weight, but also if we find in practice a modal would be better, it won't be impossible/unreasonable to change that later on. Mainly for block bindings, the feature is still so nascent that it's hard to optimize in one direction or other: it's not seen usage to fully define its flows yet. As that settles, the flow will need to be optimized for it if the first version didn't hit the mark.

[fabiankaegy]

Just noting here that ideally there should be options to control who is able to manage the allow list visually.

I can see how it would be something we would want to allow administrators to do. But not regular editors or authors.

Just adding the UI without ways to suppress it would be a step backwards in terms of how we can curate / lock down the editorial experience on highly customized builds

[gziolo]

Just adding the UI without ways to suppress it would be a step backwards in terms of how we can curate / lock down the editorial experience on highly customized builds

Does the same problem exist for locking blocks? @Mamaduka worked on it, so he should be a good person to give a good answer on how these two functionalities can evolve together as they fall into a similar bucket.

[Mamaduka]

Settings to control UI availability are described in the dev note - https://make.wordpress.org/core/2022/05/05/block-locking-settings-in-wordpress-6-0/.

P.S. Sometimes, it feels like we're deviating from the "Decisions, not options" core philosophy. Does the same philosophy not apply to block editors? How do we find the right balance when making this decision for users as a core team?

[ndiego]

Just noting here that ideally there should be options to control who is able to manage the allow list visually.

I can see how it would be something we would want to allow administrators to do. But not regular editors or authors.

💯 There needs to be a corresponding Editor setting, similar to canLockBlocks, that controls whether the user has access to this UI if implemented.

[colorful-tones]

I can see how it would be something we would want to allow administrators to do. But not regular editors or authors.

Absolutely agree. There needs to be permissions/role checks associated with this new allowedBlocks UI.

[mtias]

Is this something that should be governed by theme.json settings?

[colorful-tones]

Is this something that should be governed by theme.json settings?

A UI for this type of governance is suitable, and I would avoid theme.json.

I'm curious to hear other folk's opinions.

[mtias]

@colorful-tones I mean for disabling the UI—like you can disable certain supports, like color or typography tools.

[ndiego]

@colorful-tones I mean for disabling the UI—like you can disable certain supports, like color or typography tools.

The settings in theme.json itself are global and would impact all users. However, if the UI was governed by theme.json, you could use server-side theme.json filters to do virtually anything you wanted from an Editor curation perspective.

[colorful-tones]

I mean for disabling the UI—like you can disable certain supports, like color or typography tools.

Ok, that makes sense. 👍

Yes, theme.json ”settings” makes sense to disable the UI. 👍

[t-hamano]

If we were to move forward with this issue, perhaps we should start by refactoring the BlockManager component that renders the list of blocks with checkboxes?

Currently this component contains the logic for controlling allowedBlockTypes (blocks enabled across the editor) and hiddenBlockTypes (blocks disabled across the editor) and therefore cannot be reused for other purposes.

Because this component is not exposed, we should be allowed to make breaking changes.