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.

[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).

[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]

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.

[mtias]

@t-hamano that sounds good, yes

[t-hamano]

I think the following points need to be addressed to move this issue forward:

• Currently, the "Manage block visibility" setting doesn't work, but that should be resolved in Inserter: Fix Block visibility manager #65700.
• Add E2E tests for the Manage block visibility setting (suggested in this comment).
  Block Visibility: Add e2e test #65880
• Convert the BlockManager component into a reusable component.
  Make BlockManager component reusable #67052
• Move the BlockManager component from the editor package to the block-editor package and mark it as a private component. In my opinion, hooking here in the block-editor package would be appropriate to render the UI for allowedBlocks. However, the block-editor package doesn't depend on the editor package, so it can't import components in the editor package.
  Block Manager: Make it a private component in the block editor package #67255
• Implement a UI for allowedBlocks.

[t-hamano]

I have tried implementing this issue ahead of time. I expect it to work as follows.

iEhyyFV8rR4EolO5.mp4

One concern is that it may not be possible to place the button to toggle this UI at the very end of the Advanced panel. This is because even if we inject the UI via the InspectorControl slot, the block itself may inject the UI later (e.g. the HTML element setting of the Group block).

We might need to add a new inspector control slot here so that the allowedBlocks ui is always injected at the end of the Advanced panel.

[talldan]

I wonder if this should also be a new block supports option as well. A support hook could add the allowedBlocks attribute and the UI parts, and it'd make it easier to keep the implementation consistent across blocks

Only thing is that I don't know whether the support hooks can modify innerBlocksProps, which is how allowedBlocks is defined for blocks. 🤔

[t-hamano]

Introducing this as block support would certainly be ideal, but even if block support was added, the availability of innerblocks would be determined by the block implementation. In other words, it is possible that the allowedBlocks attribute added by block support will not be used at all.

Instead of block support, I think it might be better to introduce an editor setting similar to canLockBlocks, for example canOverrideAllowedBlocks.

This allows the availability of the UI to be modified based on user capabilities.

[t-hamano]

Update: I think we are now all set to build a UI for allowedBlocks. I would like to try out the implementation so that this UI can be released in WordPress 6.8.

[t-hamano]

Before proceeding with development, I'm considering which approach is best.

One approach is to provide a UI based on whether attributes.allowedBlocks is defined. The concern with this approach is that if an extender already defines the same attribute, the UI will be forced to be provided. Or, the extender may be using the attribute for a different purpose.

Another approach is to remove the custom attribute.allowedBlocks in the core block and add the new supports.allowedBlocks. In other words, any block that has supports.allowedBlocks will automatically have attributes.allowedBlocks defined and will also be provided with a UI.

Either way, I think it is the responsibility of the block to pass the allowedBlocks attribute to the useInnerBlocksProps parameter.