[wp-trac] [WordPress Trac] #49615: Editor: Support filtering arguments in block type registration

[WordPress Trac]

#49615: Editor: Support filtering arguments in block type registration
-------------------------+------------------------------
 Reporter:  aduth        |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Editor       |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:
-------------------------+------------------------------

Comment (by 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/49615#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform