[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.
>
> 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:
 - `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}`

--

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