Editor: Support filtering arguments in block type registration

[aduth]

Related: ​https://github.com/WordPress/gutenberg/pull/18414

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:

• ​https://developer.wordpress.org/reference/hooks/register_post_type_args/
• ​https://developer.wordpress.org/reference/hooks/register_taxonomy_args/
• ​https://developer.wordpress.org/reference/hooks/register_meta_args/

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`

[gziolo]

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.

[azaozz]

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?

[aduth]

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

​https://developer.wordpress.org/block-editor/developers/filters/block-filters/#blocks-registerblocktype

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:

​https://developer.wordpress.org/block-editor/developers/block-api/block-registration/

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.

[gziolo]

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 ​https://github.com/WordPress/gutenberg/pull/20794, 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:
​https://github.com/WordPress/gutenberg/blob/e8c7e9768c5f4eed7d5dcc92c5592424f0a52f83/webpack.config.js#L139-L180

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)

[gziolo]

This ticket introduces a new filter:

<?php
/**
 * 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 );

[gziolo]

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.

[gziolo]

Mirror client side hooks for block attributes

[gziolo]

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 ​https://github.com/WordPress/gutenberg/pull/18414/files#r449390368. All credits should go to him :)

There are also other attributes that we can discuss separately.

Trac ticket: https://core.trac.wordpress.org/ticket/49615

[gziolo]

​https://github.com/WordPress/wordpress-develop/pull/383 - 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.