#49615 closed enhancement (fixed)
Editor: Support filtering arguments in block type registration
Reported by: | aduth | Owned by: | gziolo |
---|---|---|---|
Milestone: | 5.5 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Editor | Keywords: | has-patch has-unit-tests needs-dev-note |
Focuses: | Cc: |
Description
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
, afterwp_parse_args
, for consistency with `WP_Post_Type::set_props`
Attachments (2)
Change History (14)
#2
@
5 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?
#3
@
5 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:
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.
#4
@
5 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 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 register filters that override
render_callback
for core blocks (well, here the priority might be still an issue as it's the same code)
#5
@
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
@
4 years ago
- Keywords needs-dev-note added
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 );
#8
@
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 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.
This ticket was mentioned in PR #383 on WordPress/wordpress-develop by gziolo.
4 years ago
#9
Trac ticket: https://core.trac.wordpress.org/ticket/49615
#10
@
4 years ago
- Keywords dev-feedback removed
- Resolution set to fixed
- Status changed from reopened to closed
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.
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.