In 5.0, WP_Screen::is_block_editor() was introduced to allow developers to conditionally execute code depending on whether the block editor is being loaded. This method returns the is_block_editor property of the WP_Screen instance. However, there were some large gaps in the loading process where an incorrect value could potentially be returned.
For example, when using the current_screen action hook, the value was always false, even when the user was visiting a block editor enabled screen. This happened because block editor support is flagged much later in the loading process when edit-form-blocks.php is included.
function myplugin_current_screen( $screen ) {
if ( $screen->is_block_editor ) {
// This conditional would never execute.
}
}
add_action( 'current_screen', 'myplugin_current_screen' );
This has been fixed in 5.2 to account for all possible scenarios when a post is edited. However, there are still a few very narrow edge cases when a new post is created where WP_Screen::is_block_editor() may still incorrectly indicate block editor support.
Edge Cases When Creating New Posts
The use_block_editor_for_post() function and replace_editor filter require a WP_Post object to be passed as a parameter. Because a new post has not yet been created when WP_Screen is instantiated, it can only make its best guess whether the page is loading the block editor.
When creating a new post, WP_Screen will set is_block_editor property to the value returned by use_block_editor_for_post_type() for the current post type. In most cases, this guess will be correct. But, the following scenarios have edge cases to consider.
- When the
replace_editor filter is used to replace the editor, this value may be incorrect.
- When the
use_block_editor_for_post filter is used to change block editor support.
For both of these scenarios, the use_block_editor_for_post_type filter can be used to ensure the correct value in most circumstances.
function myplugin_replace_editor_filter( $replace_editor, $post ) {
// Logic to replace editor.
}
add_filter( 'replace_editor', 'myplugin_replace_editor_filter', 10, 2 );
function myplugin_replace_editor_post_type( $use_block_editor, $post_type ) {
// Similar logic to replace editor, but without a WP_Post object to work with.
}
add_filter( 'use_block_editor_for_post_type', 'myplugin_replace_editor_post_type', 10, 2 );
With this filter, all scenarios that do not require checking a specific property of a post (a taxonomy term, meta value, etc.) can be accounted for. For example, filtering based on user capability, site option, or user meta value for editor preference are all possible using use_block_editor_for_post_type.
When WordPress creates a new post, it uses the get_default_post_to_edit() function. This function creates a new post in the database using wp_insert_post() and then allows the default content, title, and excerpt to be filtered. When terms, post meta, or content are added to posts with actions such as save_post or wp_insert_post, it is possible that this could change the block editor support for the post being created.
This scenario would result in WP_Screen:is_block_editor possessing an incorrect value from the current_screen action until roughly the load-{$pagenow}
Logic should be added to the use_block_editor_for_post_type filter to account for these scenarios (which are normally post type specific) and guarantee the accuracy of WP_Screen::is_block_editor().
For more information on this, consult the ticket on Trac (#46195), or the changeset ([45224]).
#5-2, #block-editor, #dev-notes, #gutenberg
