Inconsistent logic in allowed_block_types

[drozdz]

There are many filters like that in WP (for example mime_types, manage_posts_columns, and so on) and all of them are getting a full list of items as $allowed param. This way developers can easy manipulate the list (add, remove and so on).

On the other hand allowed_block_types takes a totally different approach. If all blocks are allowed, you get "true" as list of allowed blocks.

OK, it may look convenient, but...

1. It's inconsistent with any other WP filter...
2. It makes it really hard to blacklist blocks (let's say we want to remove only 2 blocks).
3. It makes getting the list of registered blocks impossible.

PS. I know - you can do this in JS. But I don't think that it's very convenient to put some options in PHP, store these options in DB and then in every request pass this value to JS and process it on client-side...

[swissspidy]

The main issue here is that there's currently a lack of server-side awareness of block types. See ​https://github.com/WordPress/gutenberg/issues/2751.

Without a full list of block types, it's impossible to pass all blocks to that filter.

[aurooba]

Replying to swissspidy:

The main issue here is that there's currently a lack of server-side awareness of block types. See ​https://github.com/WordPress/gutenberg/issues/2751.

Without a full list of block types, it's impossible to pass all blocks to that filter.

Has there been any work done on this issue yet? It would be extremely helpful if the server-sde had awareness of client-side blocks as well, or if all core blocks had server-side registration as well – to expose them to the server for this.