[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:
-----------------------------------------------------+---------------------
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:
> - 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`
> - `block_categories_all`
> - `block_editor_settings_all`

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 it
 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_rest_api_preload` 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`
 - `block_categories_all`
 - `block_editor_rest_api_preload_paths`
 - `block_editor_settings_all`

--

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