Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#49615 closed enhancement (fixed)

Editor: Support filtering arguments in block type registration

Reported by: aduth's profile aduth Owned by: gziolo's profile gziolo
Milestone: 5.5 Priority: normal
Severity: normal Version:
Component: Editor Keywords: has-patch has-unit-tests needs-dev-note
Focuses: Cc:



It is currently not possible to filter the settings of a block type during its registration. I would propose that this support be added for on the following basis.

  • To enable extensibility. See Gutenberg#18414 for one such example, where default block attributes are added automatically on the basis of block "supports".
  • For consistency with other register_ functions.

See prior art:

The attached patch seeks to follow this pattern:

  • Named register_block_type_args for consistency with prior art
  • Implemented in WP_Block_Type::set_props, after wp_parse_args, for consistency with `WP_Post_Type::set_props`

Attachments (2)

49615-filter-register-block-type.diff (1.8 KB) - added by aduth 4 years ago.
49615-core-blocks.diff (3.8 KB) - added by gziolo 4 years ago.
Mirror client side hooks for block attributes

Download all attachments as: .zip

Change History (14)

#1 @gziolo
4 years ago

Nice work, I second this effort. It nicely aligns with the existing filters. Code looks good, I'd appreciate some sanity check though because I don't have a lot of experience with adding new hooks in core.

#2 @azaozz
4 years ago

Code looks good here too.

My only concern is what would happen (if anything) when registered block properties are removed.

Use case:

  • Plugin adds three more props to the Paragraph block.
  • The block is used in posts, including the three props.
  • Plugin is deactivated.
  • User edits one of the older posts that includes paragraph blocks with the three (now non-registered) props.

Similarly, this filter makes it possible to remove properties from the default/core blocks. Is that supported / is it a good idea?

Last edited 4 years ago by azaozz (previous) (diff)

#3 @aduth
4 years ago

@azaozz It's a good point to raise. For what it's worth, this sort of filtering exists already client-side:

The same concerns exist (and are valid) there as well. We tend to warn about manipulating block attributes by a plugin for the exact reasons you mention: That if the plugin becomes disabled, the block may be inadvertently put into an "invalidated" state. It's perhaps worth noting that it's not necessarily guaranteed that this would occur, and there may be cases where a plugin author or site owner might even be okay with that caveat.

The question is relevant for the use-case described in the initial comment, since this sort of filtering is necessary to be able to implement default block supports in Gutenberg. But if it's the sort of thing where we are only comfortable in implementing these because we assume they would become part of some core set of supported block supports, then it raises a question about whether the code as it would expect to be implemented in core would be achieved this way (via filter), vs. by some other means (directly in the logic of register_block_type or in class WP_Block_Type_Registry, for example).

Finally, block attributes aren't the only thing one might possibly want to filter. It could be any of these:

Plus the server-side render_callback, editor_script, script, editor_style, and style.

How might that be used? Not entirely sure, but maybe:

  • Extending render_callback to add markup in addition to the default implementation (technically possible now by other means, i.e. render_block filter)
  • Changing category or keywords

So, I'm on the fence 🙂

One one hand, there's quite a bit of prior art with this sort of filtering (register_post_type_args, etc), it would bring consistency with the client-side implementation (blocks.registerBlockType filter), and it's partly granted in the intent with filtering that we won't necessarily care to know the full extent of how we'd expect the filter to be used.

On the other hand, it could be a "footgun". And at the very least, this thought exploration has me considering whether we really care to be implementing block supports in Gutenberg first, vs. just exploring the patch in core. And if so, if we might not even need this filter for that immediate use-case.

#4 @gziolo
4 years ago

The nice side-effect of using register_post_type_args is the use case where you could set render_callback using this filter and automate the block registration using some sort of block.json detection from one central place. If you combine it with the new utility function register_block_type_from_metadata I propose in, you could simplify the block registration to running a loop over the list of locations with block.json file or even provide another filter that stores the list of such locations. This way, we could avoid the whole logic in Gutenberg that plays with action priorities to ensure that core blocks are successfully overridden in the plugin:

Instead, it could be simplified to two things:

  • Gutenberg replaces the list of locations for core blocks
  • Gutenberg registers filters that override render_callback for core blocks (well, here the priority might be still an issue as it's the same code)
Last edited 4 years ago by gziolo (previous) (diff)

#5 @gziolo
4 years ago

  • Keywords has-patch has-unit-tests added
  • Milestone changed from Awaiting Review to 5.5
  • Owner set to gziolo
  • Status changed from new to assigned

#6 @gziolo
4 years ago

  • Keywords needs-dev-note added

This ticket introduces a new filter:

 * Filters the arguments for registering a block type.
 * @since 5.5.0
 * @param array  $args       Array of arguments for registering a
 *                           block type.
 * @param string $block_type Block type name including namespace.
$args = apply_filters( 'register_block_type_args', $args, $this->name );

#7 @gziolo
4 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 48263:

Editor: Support filtering arguments in block type registration

Adds possibility to filter the settings of a block type during its registration.

Props aduth, azaozz.
Fixes #49615.

4 years ago

Mirror client side hooks for block attributes

#8 @gziolo
4 years ago

  • Keywords dev-feedback added
  • Resolution fixed deleted
  • Status changed from closed to reopened

The newly added patch mirrors the implementation where the client injects attributes based on supports flag set:

  • className
  • align
  • anchor

It's based on proposal from @aduth included in All credits should go to him :)

There are also other attributes that we can discuss separately.

#10 @gziolo
4 years ago

  • Keywords dev-feedback removed
  • Resolution set to fixed
  • Status changed from reopened to closed - needs more work. I chatted with @youknowriad and he pointed out that there are more supports properties that need to be covered, let's do it separately as part of WordPress 5.6 release cycle.

For 5.5 we only added the filter register_block_type_args that requires a dev note.

This ticket was mentioned in Slack in #core by justinahinon. View the logs.

4 years ago

This ticket was mentioned in Slack in #core-editor by justinahinon. View the logs.

4 years ago

Note: See TracTickets for help on using tickets.