WordPress.org

Make WordPress Core

Opened 9 months ago

Last modified 9 months ago

#46129 new enhancement

Inconsistent logic in allowed_block_types

Reported by: drozdz Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: General Keywords:
Focuses: Cc:
PR Number:

Description

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

Change History (1)

#1 @swissspidy
9 months ago

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.

Note: See TracTickets for help on using tickets.