Block API: Allow blocks to register their compatibility with black/whitelists

[jasmussen]

This one is a bit exotic, and please feel free to add to this ticket, or edit it, to expand upon the details.

Our API right now allows a plugin to filter out certain blocks. This is useful if, for example, an institution would like to hide the "YouTube Embed" block. A blacklist usecase, sort of.

Or perhaps another plugin can register itself as requiring the user to use only basic text blocks, so no blocks are used that break the layout of a specific setup. This would be more of a whitelist.

Now imagine WordPress gets updated with a new block. In the blacklist usecase, this block would suddenly show up out of the blue, because the blacklist hasn't been updated, perhaps inappropriately so. In the case of the whitelist, this new block wouldn't show up at all, which might be a great loss since it would be a cool thing to have.

Can we let blocks register properties that can help guide such filters? For example, could we let a block register itself as G, or PG (like Gravatars), or even xhtml-compatible, or no-js-compatible, or any number of other properties that might make sense to inform filters of?

[brentjett]

I agree this would be helpful. We do something similar in BB to let users/admins curate the registered module list manually. Custom plugins that declare a special post type will likely want to also declare special blocks available only to their post type.

[mtias]

Closing this as you can whitelist blocks for a CPT now.

[jasonbahl]

Why was this closed? The proposal was for blocks to register their support for various other parts of the Gutenberg interface. . .custom post types is a tiny part of that.

Gutenberg doesn't even support Page Templates yet, but when it does, this would be a perfect use case for that. custom-block-xx could register support for page-template-xx and be shown in the list of blocks you can add to that template, or alternatively page-template-xx could declare support for custom-block-xx.

But as @jasmussen mentioned, the conditions are pretty endless. I could easily see some blocks being related to post_status even. In editorial workflows, I could easily see some blocks, such as a hypothetical "editorial comment blocks" being allowed to be added between/next to other blocks if the status is draft, but on publish the block could no longer be added.

Also a newsroom example, I could see conditions re: user roles/capabilities. Like a writer could add/manipulate text blocks, and a photographer/photo-editor could add/manipulate image/gallery blocks.

The conditions go on and on. Being able to declare what blocks support what conditions seems like an important API to think more about. . .not sure what it needs to look like, but closing this issue seems pre-mature to me 🤔

[brandonpayton]

@jasonbahl Does the presence of an allowed_block_types filter address any of your concerns? A recent PR added a $post argument to the filter, though based on your comments, I wonder if that will be sufficient.

[jasonbahl]

@brandonpayton even that filter doesn't fully define what block types are allowed or not. . .it does remove them from the inserter, but it doesn't affect the Transform into: control.

Probably need to open another issue pointing that out. . .that blocks should only be able to be transformed into other "allowed" blocks.