[wp-trac] [WordPress Trac] #53233: Editor: Extend `register_block_type` to accept the path file or folder with `block.json`

[WordPress Trac]

#53233: Editor: Extend `register_block_type` to accept the path file or folder with
`block.json`
-----------------------------------------------------+---------------------
 Reporter:  gziolo                                   |       Owner:  gziolo
     Type:  enhancement                              |      Status:  closed
 Priority:  normal                                   |   Milestone:  5.8
Component:  Editor                                   |     Version:  trunk
 Severity:  normal                                   |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests needs-dev-note  |     Focuses:
-----------------------------------------------------+---------------------

Comment (by Clorith):

 I'm totally on board with the idea of having one canonical function for
 registering blocks, but I'm a bit worried about the implementation and
 direction as it stands.

 WordPress 5.7 had changes which made a lot of folks switch from
 `register_block_type` to `register_block_type_from_metadata` because of
 new requirements in registering attributes, which non-serverside blocks
 often did not declare to PHP, as it wasn't required. Making this swap made
 the transition less troublesome than having to re-declare everything in
 multiple locations.

 The patch committed in [50927] maintains backwards compatibility by
 checking if it's a legitimate path provided, or a string (which should be
 interpreted as the block slug), but given that this is becoming canonical,
 it is not unreasonable to presume that `register_block_type_from_metadata`
 will be getting a `__doing_it_wrong()` when called directly in the future,
 reversing the current need folks had just one release back to switch to
 this function.

 It's also not possible for folks to future, or backwards proof their code,
 since the file path can only be provided in 5.8 or above, meaning they'd
 (potentially) end up with three implementations depending on which WP
 versions they support.

 I also fear this hurts an already strained developer relationship where
 there's murmur of too many breaking changes between each core release due
 to the block editor.

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