is_block_editor() returns inconsistent result in core versus in plugin

[mattyrob]

What problem does this address?

At the moment the logic required in plugins or themes for hooking block code for the new Widget Screen and Widget Customizer needs to be extended beyond simply checking if is_block_editor() evaluates to true because on those screens it currently returns false.

What is your proposed solution?

$current_screen->is_block_editor() should evaluate to true on all screen where plugins and themes are able to extend the core Block Editor.

As such this should extend to screens where $current_screen->id is in the following list:
widgets
customize
appearance_page_gutenberg

And there may well be others I have not tripped over yet.

[talldan]

The code for the widget screen was merged to core yesterday and included this:
https://github.com/WordPress/wordpress-develop/pull/1284/files#diff-0ed28dcc06a2097b0b6ea754f3d111cf434a4ab555e91eeb8abf7c343bc500d4R16

So I think is_block_editor will be true in WordPress 5.8.

The Gutenberg plugin has done things a different way using the filter below, and I don't think that modifies the is_block_editor value (it remains false):

gutenberg/lib/widgets-page.php

Lines 83 to 91 in 87ad8f3

	function gutenberg_widgets_editor_load_block_editor_scripts_and_styles( $is_block_editor_screen ) {
	if ( is_callable( 'get_current_screen' ) && 'appearance_page_gutenberg-widgets' === get_current_screen()->base ) {
	return true;
	}
	return $is_block_editor_screen;
	}
	add_filter( 'should_load_block_editor_scripts_and_styles', 'gutenberg_widgets_editor_load_block_editor_scripts_and_styles' );

So this is probably something we want to revisit in terms of the plugin. I think it should be consistent with core, else we might see some unexpected issues.

I remember I did propose making is_block_editor true in the plugin (#26263), but the setting has some unexpected side effects. Conversation here:
WordPress/wordpress-develop#603 (comment)

For the customizer, that's a bit of a more nuanced situation since the widget editor is only a small part of the customizer experience, but you're right in that there needs to be some assurances that block based plugins should work. I know we've tested a number of plugins and they don't seem to have any issues (beyond a few known ones).

[mattyrob]

@talldan

Thanks for the response and pointers to the code snippets.

I have implemented a local var_dump() to assess the status of is_block_editor() and 'should_load_block_editor_scripts_and_styles' and it is very inconsistent.

On edit.php when editing a post these return true and (I think) null.
On widgets.php these return false and null.
On customize.php these return false and true.

This inconsistency makes it quite a challenge to ensure plugin code is loaded where it is needed.

[noisysocks]

I think let's make it like this in both core and the plugin:

	$current_screen->is_block_editor()	should_load_block_editor_scripts_and_styles
edit.php	true	true
widgets.php	true	true
customize.php	false	true

In retrospect I think we never should have added $current_screen->is_block_editor(). A block editor is a component which can be inserted into a screen. There can be multiple block editors in a screen. Alas, here we are 🙂

[noisysocks]

This is related to #28517. We ought to move away from is_block_editor (but keep it working like in the table above for backwards compatibility) and instead rely on WP_Block_Editor_Context to determine what editor we're in. See #28517 (comment).

[jordesign]

@noisysocks @mattyrob Just wanted to check if this is still occuring in WP6.3 or if it has been resolved?

[mattyrob]

@jordesign - I'm not sure I'm in a position to answer as I moved away from relying on is_block_editor due to the inconsistencies.

On a quick check today in WordPress 6.3 it seems it now only evaluates to true in edit.php and is false is widgets.php and customize.php now also.

I am unable to comment on what should_load_block_editor_scripts_and_styles returns currently and I'm not sure how that would be debugged or tested.

[jordesign]

No worries at all @mattyrob - I'll leave this open so it can be further investigated