[wp-trac] [WordPress Trac] #50653: Remove the _doing_it_wrong from WP_Block_Patterns_Registry::unregister()

[WordPress Trac]

#50653: Remove the _doing_it_wrong from WP_Block_Patterns_Registry::unregister()
-----------------------------------+---------------------
 Reporter:  johnbillion            |       Owner:  (none)
     Type:  defect (bug)           |      Status:  new
 Priority:  normal                 |   Milestone:  5.5
Component:  Editor                 |     Version:  trunk
 Severity:  normal                 |  Resolution:
 Keywords:  has-patch 2nd-opinion  |     Focuses:
-----------------------------------+---------------------
Changes (by SergeyBiryukov):

 * keywords:  has-patch => has-patch 2nd-opinion


Comment:

 Replying to [comment:1 youknowriad]:
 > I don't feel strongly personally but this is modeled over existing block
 style variations and block types registries. If we make a change, we
 should check that it's consistent with other registries.

 I agree with that. For reference, here's the list of classes and methods
 that follow the pattern:

 * `WP_Block_Pattern_Categories_Registry::(un)register()` (introduced in
 5.5.0).
 * `WP_Block_Patterns_Registry::(un)register()` (introduced in 5.5.0)
 * `WP_Block_Styles_Registry::(un)register()` (introduced in 5.3.0)
 * `WP_Block_Type_Registry::(un)register()` (introduced in 5.0.0)

 While there should be no back compat concerns in changing the former two,
 there should be an investigation of possible side effects for changing the
 latter two.

 While I agree switching all of these to return `WP_Error` on failure would
 make sense, changing only one or two classes would bring an inconsistency
 without a strong reason. I think being consistent in our APIs outweights
 the benefits of such a change.

 I'd suggest either changing all of these at once, or just going with the
 existing approach.

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