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

WordPress Trac noreply at wordpress.org
Fri Mar 26 11:45:49 UTC 2021


#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    |     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 proposed so far:
>
> - 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 get exposed from the new
> `get_default_block_editor_settings` method
> - shared block editor configuration gets abstracted in the new
> `block_editor_configure` method
>
> To explore:
>
> -  deprecating existing filters with `apply_filters_deprecated` as
> suggested by @jeremyfelt:
>     - `allowed_block_types`
>     - `block_editor_preload_paths`
>     - `block_categories`
> - introducing new filters that aren't tied to the `$post` object

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.

 Changes proposed so far:

 - 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 get exposed from the new
 `get_default_block_editor_settings` method
 - shared block editor configuration gets abstracted in the new
 `block_editor_configure` method
 - `wp-format-library` assets are always loaded for the block editor with
 the corresponding hook

 To explore:

 -  deprecating existing filters with `apply_filters_deprecated` as
 suggested by @jeremyfelt:
     - `allowed_block_types`
     - `block_editor_preload_paths`
     - `block_categories`
 - introducing new filters that aren't tied to the `$post` object

--

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


More information about the wp-trac mailing list