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

[WordPress Trac]

#52920: Editor: Abstract block editor configuration
---------------------------------------------------+---------------------
 Reporter:  gziolo                                 |       Owner:  (none)
     Type:  enhancement                            |      Status:  new
 Priority:  normal                                 |   Milestone:  5.8
Component:  Editor                                 |     Version:
 Severity:  normal                                 |  Resolution:
 Keywords:  has-patch has-unit-tests dev-feedback  |     Focuses:
---------------------------------------------------+---------------------
Description changed by gziolo:

Old description:

> We are approaching the day where new screens with the block editor get
> included in WordPress core. It looks like there are several WordPress
> hooks defined on the server that depends on `$post` object that isn’t
> present on the edit site, edit widgets, or edit navigation screens. It
> feels like we should deprecate existing filters and create replacements
> that are going to be context-aware.
>
> Prior art in Gutenberg:
> https://github.com/WordPress/gutenberg/pull/28701.
>
> Required for https://github.com/WordPress/gutenberg/pull/29969 - new REST
> API endpoint for the editor settings.
>
> Changes included so far:
> - `wp-format-library` assets are always loaded for the block editor with
> the corresponding hook
> - most of the settings that are defined on the client in the block editor
> package in https://github.com/WordPress/gutenberg/blob/trunk/packages
> /block-editor/src/store/defaults.js are already exposed from the new
> `get_default_block_editor_settings` method
> - the logic that preloads common data used with the block editor by
> processing an array of REST API paths is now abstracted in
> `block_editor_preload_api_requests` method
>
> All existing filters that depend on `$post` object get deprecated with
> `apply_filters_deprecated` as suggested by @jeremyfelt:
> - `allowed_block_types`
> - `block_editor_preload_paths`
> - `block_categories`
>
> New filters are introduced that are context-aware:
> - `allowed_block_types_{$editor_name}`
> - `block_editor_preload_paths_{$editor_name}`
> - `block_categories_{$editor_name}`

New description:

 We are approaching the day where new screens with the block editor get
 included in WordPress core. It looks like there are several WordPress
 hooks defined on the server that depends on `$post` object that isn’t
 present on the edit site, edit widgets, or edit navigation screens. It
 feels like we should deprecate existing filters and create replacements
 that are going to be context-aware.

 Prior art in Gutenberg: https://github.com/WordPress/gutenberg/pull/28701.

 Required for https://github.com/WordPress/gutenberg/pull/29969 - new REST
 API endpoint for the editor settings.

 Changes included so far:
 - new method `get_default_block_categories` were introduced to make is
 possible to share default block categories
 - new method `get_allowed_block_types` was introduced to handle filters
 depending on the editor type
 - most of the settings that are defined on the client in the block editor
 package in https://github.com/WordPress/gutenberg/blob/trunk/packages
 /block-editor/src/store/defaults.js are already exposed from the new
 `get_default_block_editor_settings` method
 - another method `get_block_editor_settings` got introduced to ensure that
 editor settings can be filtered depending on the editor type
 - the logic that preloads common data used with the block editor by
 processing an array of REST API paths is now abstracted in
 `block_editor_preload_api_requests` method

 All existing filters that depend on `$post` object get deprecated with
 `apply_filters_deprecated` as suggested by @jeremyfelt:
 - `allowed_block_types`
 - `block_categories`
 - `block_editor_preload_paths`
 - `block_editor_settings`

 New filters are introduced that are context-aware:
 - `allowed_block_types_all`
 - `allowed_block_types_{$editor_name}`
 - `block_categories_all`
 - `block_editor_preload_paths_{$editor_name}`
 - `block_editor_settings_all`
 - `block_editor_settings_{$editor_name}`

 In the case where there are two filters for a general use case that covers
 any editor type and a specific one, I followed #46187 and the
 implementation for `render_block` + `render_block_{$block_name}`.
 @johnbillion shared more examples in
 https://core.trac.wordpress.org/ticket/46187#comment:9:

 > This is a fairly common pattern in core, see for example:
 `gettext/gettext_{$domain}`,
 `plugin_action_links/plugin_action_links_{$plugin_file}`,
 `manage_posts_columns/manage_{$post_type}_posts_columns`, etc. The
 dynamically named filter should come after the generic one.

--

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