WordPress.org

Make WordPress Core

Opened 3 weeks ago

Last modified 21 hours ago

#52920 new enhancement

Editor: Abstract block editor configuration

Reported by: gziolo 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 gziolo)

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)

#1 @gziolo
3 weeks ago

  • Description modified (diff)

This ticket was mentioned in PR #1125 on WordPress/wordpress-develop by gziolo.


3 weeks ago

Trac ticket: https://core.trac.wordpress.org/ticket/52920

Ensures that wp-format-library assets are always loaded for the block editor.

#3 @gziolo
3 weeks ago

  • Description modified (diff)

#4 @prbot
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 @prbot
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 with enqueue_editor_block_styles_assets

#6 @prbot
2 weeks ago

ellatrix commented on PR #1125:

You mean for WordPress? I guess so, otherwise it should just have no formats available without errors.

#7 @prbot
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 @prbot
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.

#9 @gziolo
12 days ago

  • Keywords has-unit-tests dev-feedback added

#10 @gziolo
12 days ago

  • Description modified (diff)

#11 @gziolo
12 days ago

  • Description modified (diff)

#12 @SergeyBiryukov
12 days ago

Just linking [50620] for reference, apparently it missed the ticket.

#13 @SergeyBiryukov
12 days ago

In 50629:

Editor: Consolidate enqueueing block editor assets in wp-includes/default-filters.php.

Follow-up to [44157], [46111], [48537], [50620].

See #52920.

#14 @prbot
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 @prbot
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 the block_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) or get_block_editor_settings (if they are only relevant to a specific editor).

Does this sound about right to you?

#17 @prbot
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.

Note: See TracTickets for help on using tickets.