Opened 3 weeks ago
Last modified 21 hours ago
#52920 new enhancement
Editor: Abstract block editor configuration
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | 5.8 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Editor | Keywords: | has-patch has-unit-tests dev-feedback |
Focuses: | Cc: |
Description (last modified by )
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}
Change History (17)
This ticket was mentioned in PR #1125 on WordPress/wordpress-develop by gziolo.
3 weeks ago
#4
@
2 weeks ago
azaozz commented on PR #1118:
It feels like we should deprecate existing filters and create replacements that are going to be context-aware.
The changes so far look good imho. Thinking this can go a step further, perhaps, and clearly separate/define the (PHP) filters that run for the actual editor (settings, UI, etc.) and the filters that run for the things around the editor (tags, categories, etc.). Would make it clearer/easier to understand and eventually add/tweak/remove filters in the future.
#5
@
2 weeks ago
gziolo commented on PR #1125:
@youknowriad and @ellatrix – do you think it's safe to assume that we always need to load format library?
We do something similar for:
- block directory with
wp_enqueue_editor_block_directory_assets
- block styles from
WP_Block_Styles_Registry
withenqueue_editor_block_styles_assets
#7
@
13 days ago
gziolo commented on PR #1125:
You mean for WordPress? I guess so, otherwise it should just have no formats available without errors.
Yes, for WordPress. It's going to be loaded for all pages that render the block editor moving forward. Related commit: https://github.com/WordPress/wordpress-develop/commit/0df28171ed9c3c31ebc93add82b64df8f690f87c.
#8
@
12 days ago
gziolo commented on PR #1118:
I applied several iterations and added tests to cover some of the methods and filters that are marked as deprecated. It still needs more tests and one more abstraction as discussed in https://github.com/WordPress/wordpress-develop/pull/1118#discussion_r605516157 but I think it's close to what I would expect. Any thoughts on the current shape? I'd like to start committing parts of the codebase next week if there are no further concerns.
#14
@
4 days ago
gziolo commented on PR #1118:
A note to myself.
The list of filters covered with unit tests:
- [x]
allowed_block_types
- [x]
allowed_block_types_{$editor_name}
- [x]
block_categories
- [ ]
block_editor_preload_paths
- [x]
block_editor_settings
- [x]
block_categories_{$editor_name}
- [ ]
block_editor_preload_paths_{$editor_name}
- [x]
block_editor_settings_{$editor_name}
The list of methods covered with unit tests
- [x]
get_default_block_categories
(indirectly – it's a hardcoded list) - [x]
get_block_categories
- [x]
get_allowed_block_types
- [x]
get_default_block_editor_settings
- [x]
get_block_editor_settings
- [ ]
block_editor_preload_api_requests
#15
@
4 days ago
nosolosw commented on PR #1118:
This looks good and brings clarity about the different editors and settings. Nice work! Trying to understand how to juggle these changes with the plugin and, particularly, with the addition of global styles settings to the mix. I'm thinking out loud here, it looks like the next steps are:
- Port the
get_default_block_editor_settings
as a shim to the plugin, verbatim. You already have this at https://github.com/WordPress/gutenberg/pull/30245 This is a shim to be removed as soon as the minimum WordPress version for the plugin is 5.8. - In the plugin, all new editors start using the new editor-specific filters.
- In the plugin, for the post editor, the plugin hooks into the
block_editor_settings
and runs theblock_editor_settings_post_editor
filter. All our code uses the editor-specific filter. When the minimum WordPress version for the plugin is 5.8 we switch to hook into the editor-specific filter instead. - In subsequent cycles, the new settings to port to WordPress core will be added to either
get_default_block_editor_settings
(if they're common to all editors) orget_block_editor_settings
(if they are only relevant to a specific editor).
Does this sound about right to you?
#16
@
22 hours ago
gziolo commented on PR #1118:
Gutenberg some of the deprecated filters:
allowed_block_types
block_categories
block_editor_preload_paths
block_editor_settings
- https://github.com/WordPress/gutenberg/blob/2c0ba0758d48a530596f4977c272d3a35906b215/lib/global-styles.php#L171
- https://github.com/WordPress/gutenberg/blob/7c134eb66f1e5ed67db646e19234d9edf6e3090e/lib/client-assets.php#L673
- https://github.com/WordPress/gutenberg/blob/7c134eb66f1e5ed67db646e19234d9edf6e3090e/lib/client-assets.php#L690
- and more ...
#17
@
21 hours ago
gziolo commented on PR #1118:
@nosolosw, it's a tough problem. I'm still unsure how to handle the deprecation of filters and add more general versions that don't depend on the $post
object not present in some contexts. I did some searching in the Gutenberg plugin to better understand how we use those filters today. For example, the usage of the block_categories
filter makes me want to have a way to set this category for all screens at once rather than calling it for every screen individually.
Trac ticket: https://core.trac.wordpress.org/ticket/52920
Ensures that
wp-format-library
assets are always loaded for the block editor.