Block Editor: Apply allowed_block_types filter to registered blocks

[Bernhard Reiter]

The ​`allowed_block_types` hook filters a list of blocks. Alternatively, it's possible to pass a bool to indicate that either all blocks are allowed (true), or none of them are (false).

It's currently ​applied in lib/edit-form-blocks.php to a default value of true -- meaning all blocks are allowed.

However, this means that the filter can only really be used for an allowlist, but not for a denylist: Since we don't really have access to the full list of available blocks from the filter (but just that true bool), we cannot choose to remove a set of blocks from that list.

I'm thus suggesting to pass the full list of registered blocks to the filter as the default value instead.

The ​`allowed_block_types` hook filters a list of blocks. Alternatively, it's possible to pass a bool to indicate that either all blocks are allowed (true), or none of them are (false).

It's currently ​applied in lib/edit-form-blocks.php to a default value of true -- meaning all blocks are allowed.

However, this means that the filter can only really be used for an allowlist, but not for a denylist: Since we don't really have access to the full list of available blocks from the filter (but just that true bool), we cannot choose to remove a set of blocks from that list.

I'm thus suggesting to pass the full list of registered blocks to the filter as the default value instead.

Trac ticket: https://core.trac.wordpress.org/ticket/50706

Use case example: ​https://github.com/WordPress/gutenberg/pull/24006

cc/ @TimothyBJacobs @youknowriad

Makes sense to me!

No objections from me either but curious about backward compatibility implications.
it also seems we'd have to wait for trunk to target 5.6 to land this.

I _think_ this should be mostly backward compatible, since the hook always accepted either an array of block names, or a bool, so filters attached to the hook would have to check with which of either they were dealing. In practice, they couldn't count on getting an array from which they could remove something, so the filter was only used for allow lists rather than deny lists. (As e.g. the ​docs show.) So I think we're adding functionality without really impacting existing usage.

Furthermore, the filter is applied right before the $settings var is passed to the client, so all server-side block registrations can be expected to have happened by this time.

LMK if you're thinking of a scenario that I'm missing :thinking:

Ping @TimothyBJacobs and @youknowriad -- Are we cool to merge this? :smile:

I've been thinking more here and I think we should not move forward with this. The reason being that all blocks are not registered on the server, so as implemented here, it means all the blocks registered on the frontend are not allowed by default.

@ockham sounds like we should close out this PR?

[helen]

Changing keywords here just for tracking - @youknowriad please close if not moving in this direction.

I've been thinking more here and I think we should not move forward with this. The reason being that all blocks are not registered on the server, so as implemented here, it means all the blocks registered on the frontend are not allowed by default.

@youknowriad That makes sense, but it also limits the potential use cases of the server-side filter significantly: It can basically never be used as a denylist. IMO, this raises the question of the general usefulness of this filter -- since there are also client-side mechanisms to _both_ register or unregister a block. Should we:

1. prescribe that blocks _must_ be registered on the server side?
2. deprecate the allowed_block_types hook?

Yeah the only times I've been able to use allowed_block_types is when there are a very specific set of blocks allowed which is rarely what you want. Maybe add a disabled_block_types filter?

Yeah the only times I've been able to use allowed_block_types is when there are a very specific set of blocks allowed which is rarely what you want. Maybe add a disabled_block_types filter?

Yeah, that could work :thinking: It might not perfectly cover cases where e.g. you'd like to remove all blocks in a certain namespace (rather than listing them explicitly, because e.g. they might come from a plugin that has added more blocks in more recent versions), but I guess it's a start...

We could support including a namespace in the list, so both my-plugin and other-plugin/block.

Closing this PR as the associate Trac ticket https://core.trac.wordpress.org/ticket/50706 was closed 7 weeks ago.

If any maintainer or committer feels this ticket and PR should be reopened, please update accordingly.