enqueue_block_editor_assets is not fired on /wp-admin/themes.php?page=gutenberg-widgets

[izimuth]

Description

the enqueue_block_editor_assets action is not fired on the widget editor screen defined by the gutenberg plugin

Step-by-step reproduction instructions

write a function to be called when enqueue_block_editor_assets is triggered like:

function test_enqueue_block_editor_assets()
{
    die("should break the screen");
}
add_action("enqueue_block_editor_assets", "test_enqueue_block_editor_assets");

Expected behaviour

It should display a white screen with the message shown above

Actual behaviour

The widget editor screen loads as normal, any custom scripts enqueued in the function above will not actually load

WordPress information

• WordPress version: 5.6
• Gutenberg version: 9.8.2
• Are all plugins except Gutenberg deactivated? No because my plugin is activated to test this bug
• Are you using a default theme (e.g. Twenty Twenty-One)? No, But the issue is reproducible with a default theme anyway

Device information

• Device: Desktop
• Operating system: Windows 10
• Browser: Firefox

[izimuth]

I am able to work around this by adding

	if (!is_admin())
		return;

to the beginning of the function and hooking into enqueue_block_assets instead of enqueue_block_editor_assets

i'm not sure if this is the ideal solution though.

[izimuth]

if it helps - I'm not familiar with the wordpress core codebase at all, but - i searched my folder for 'enqueue_block_editor_assets' and found only one instance where its explicitly triggered by a call to do_action in edit-form-blocks.php on line 395

[gwwar]

I verified that enqueue_block_editor_assets fires in an edit-post context, but does not on a page load of /wp-admin/themes.php?page=gutenberg-widgets. I'm not sure if this hook is supposed to work on the widgets page.

[gwwar]

Following up on this, @noisysocks noted that

The goal is to have the new widgets screen support as many of the old filters as is possible but it likely won’t be all of the old filters as there are some irreconcilable differences between the two screens. (https://wordpress.slack.com/archives/C01D71823PB/p1612393996060000)

A documentation issue to help clarify what filters are available in what contexts is being tracked here: #28710

[izimuth]

Ok but I am not using an old filter, i am trying to use the 'enqueue_block_editor_assets' filter so that my custom blocks are usable on the widgets screen.

[noisysocks]

I can confirm that enqueue_block_editor_assets is not being called in the widgets screen, navigation screen, and in the site editor.

Whether it should be called in these screens is an interesting question. I think it probably makes sense for there to be a generic enqueue_block_editor_assets action which is called on all four screens and then a more specific enqueue_block_editor_assets-$screen action which can be used to target one screen but not the others.

But I know that we already have a few related actions and filters e.g. enqueue_block_assets, should_load_block_editor_scripts_and_styles, and admin_enqueue_scripts. I think the first step here should be to do a little audit, straighten out how these actions and filters are related, document them, and then evaluate what's missing. This could get really complicated if we add a new action without first getting out house in order.

[draganescu]

I am closing this in favor of #25945 as the reason is the page not being found as an admin page. Will port @noisysocks 's comment over.