[wp-trac] [WordPress Trac] #52920: Editor: Abstract block editor configuration

[WordPress Trac]

#52920: Editor: Abstract block editor configuration
-----------------------------------------------------+---------------------
 Reporter:  gziolo                                   |       Owner:  gziolo
     Type:  enhancement                              |      Status:  closed
 Priority:  normal                                   |   Milestone:  5.8
Component:  Editor                                   |     Version:
 Severity:  normal                                   |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests needs-dev-note  |     Focuses:
-----------------------------------------------------+---------------------

Comment (by jadpm):

 Replying to [comment:25 gziolo]:
 > @jeremyfelt, that would be ideal to go with the approach you outlined.
 We are discussing the same issue in
 https://github.com/WordPress/gutenberg/pull/31027. Let me share the part
 that worries me the most if we go this route:
 >
 > `block_categories` and other filters involved here, they have the
 `$post` object as a param which is not set outside of the edit post page.
 > ...
 > If you have some ideas on how to address it safely then we should do it.

 My 2c on this topic although I know I am a bit late: why no just keep
 them?

 As stated above, there are lost of wild usages of the now deprecated
 filters that rely precisely on the parameter that is not available on the
 broad, generic new filters. I would suggest keeping the previous, existing
 filters, and document that they are **only available for the `post-editor`
 context**. This is not a breaking change at all: right now, they are only
 available there anyway!


 Otherwise, we will end up finding that developers are just repeating the
 logic now placed under deprecation, but manually: they will hook into
 `block_categories_all`, check that the editor name is `post-editor`, get
 the current post with `get_post` and evaluate whether they want to include
 their block categories **on the post editor** based on the post
 properties. I really wonder why we would want to force them to do so when
 the logic for that already exists.

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