WordPress.org

Make WordPress Core

Opened 3 weeks ago

Last modified 3 days ago

#50706 accepted defect (bug)

Block Editor: Apply allowed_block_types filter to registered blocks

Reported by: Bernhard Reiter Owned by: youknowriad
Milestone: 5.6 Priority: normal
Severity: normal Version:
Component: Editor Keywords: has-patch commit
Focuses: Cc:

Description

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.

Change History (9)

This ticket was mentioned in PR #419 on WordPress/wordpress-develop by ockham.


3 weeks ago

  • Keywords has-patch added

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

#3 @SergeyBiryukov
3 weeks ago

  • Component changed from General to Editor

#4 @prbot
2 weeks ago

ockham commented on PR #419:

cc/ @TimothyBJacobs @youknowriad

#5 @prbot
2 weeks ago

TimothyBJacobs commented on PR #419:

Makes sense to me!

#6 @prbot
2 weeks ago

ockham commented on PR #419:

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:

#7 @youknowriad
2 weeks ago

  • Keywords commit added
  • Milestone changed from Awaiting Review to 5.6

#8 @youknowriad
2 weeks ago

  • Owner set to youknowriad
  • Status changed from new to accepted

#9 @prbot
3 days ago

ockham commented on PR #419:

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

Note: See TracTickets for help on using tickets.