WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 7 months ago

#46129 reopened enhancement

Inconsistent logic in allowed_block_types

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

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 (4)

#1 follow-up: @swissspidy
3 years 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.

#2 in reply to: ↑ 1 @aurooba
7 months ago

  • Resolution set to invalid
  • Status changed from new to closed

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.

#3 @SergeyBiryukov
7 months ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

#4 @SergeyBiryukov
7 months ago

  • Component changed from General to Editor
Note: See TracTickets for help on using tickets.