Editor: Support filtering arguments in block type registration from metadata

[gziolo]

Related: ​https://github.com/WordPress/gutenberg/pull/25220, #49615

With changes added in #49615, it is possible to filter the settings of a block type during its registration with register_block_type_args. However, when working ​https://github.com/WordPress/gutenberg/pull/25220, we discovered that it is still not enough for the case when blocks are registered with block.json metadata. As of today, all core blocks are registered this way and it's impossible to customize the way their styles and scripts are registered or i18n support is handled. The idea here is to add more filters to give more options for plugin authors in the future and account for the needs that Gutenberg has in the constant work to improve the experience around block registration.

The attached patch seeks to follow with 2 new hooks:

• Named block_type_metadata to filter the content of metadata read from block.json
• Named block_type_metadata_settings to filter the settings object determined from the metadata that is passed to register_block_type call

I'm 100% sure we need the first one. In terms of adding the second one I'm open to discussion since it might
duplicate the scope of register_block_type_args with the only difference that it contains also the metadata object as an argument passed for processing.

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

Related: ​https://github.com/WordPress/gutenberg/pull/25220, https://core.trac.wordpress.org/ticket/49615

With changes added in https://core.trac.wordpress.org/ticket/49615, it is possible to filter the settings of a block type during its registration with register_block_type_args. However, when working ​https://github.com/WordPress/gutenberg/pull/25220, we discovered that it is still not enough for the case when blocks are registered with block.json metadata. As of today, all core blocks are registered this way and it's impossible to customize the way their styles and scripts are registered or i18n support is handled. The idea here is to add more filters to give more options for plugin authors in the future and account for the needs that Gutenberg has in the constant work to improve the experience around block registration.

The attached patch seeks to follow with 2 new hooks:

• Named pre_register_block_type_from_metadata to filter the content of metadata read from block.json
• Named post_register_block_type_from_metadata to filter the settings object determined from the metadata that is passed to register_block_type call

I'm 100% sure we need the first one. In terms of adding the second one, I'm open to discussion since it might duplicate the scope of register_block_type_args with the only difference that it contains also the metadata object as an argument passed for processing.

@swissspidy thank you for feedback. I will apply changes tomorrow 👍

[gziolo]

I'm 100% sure we need the first one. In terms of adding the second one I'm open to discussion since it might duplicate the scope of register_block_type_args with the only difference that it contains also the metadata object as an argument passed for processing.

I was thinking about that, I think that both filters make sense. The one that is called just before register_block_type call is very important from the perspective of Gutenberg as it's the only way to map new values added to block.json file in the plugin into values that are going to be passed as settings object to register_block_type call.

[gziolo]

In 49948:

Editor: Support filtering arguments in block type registration from metadata

Adds 2 new hooks in register_block_type_from_metadata:

• Named block_type_metadata to filter the content of metadata read from block.json
• Named block_type_metadata_settings to filter the settings object determined from the metadata that is passed to register_block_type call

Props swissspidy.
Fixes #52138.

[gziolo]

@audrasjb, I forgot to add the label myself. Sorry about that. Is the code comments enough to compile the dev note or should I prepare something as a comment?

[audrasjb]

No worry, the commit message and the code comments are clear enough to compile the dev note @gziolo :)