PHP unit tests are failing

[ockham]

Description

First reported in Slack.

PHP unit tests in the Gutenberg repo have been failing since some time after 13:56 UTC and before 14:20 UTC. Unfortunately, this seems to point at my own core commit (from 14:14 UTC)

The failure is

Step-by-step reproduction instructions

Check any commit on GB's trunk that was merged after 2022-10-24 14:14 UTC.

Its PHP unit tests are failing with

There was 1 error:

1) WP_Navigation_Page_Test::test_gutenberg_navigation_init_function_generates_correct_preload_paths
Array to string conversion

/var/www/html/wp-content/plugins/gutenberg/lib/compat/wordpress-6.0/client-assets.php:76
/var/www/html/wp-content/plugins/gutenberg/lib/compat/wordpress-6.0/client-assets.php:109
/var/www/html/wp-includes/class-wp-hook.php:310
/var/www/html/wp-includes/plugin.php:205
/var/www/html/wp-includes/block-editor.php:[53](https://github.com/WordPress/gutenberg/actions/runs/3313985686/jobs/5472682507#step:8:54)9
/var/www/html/wp-content/plugins/gutenberg/lib/experimental/navigation-page.php:109
/var/www/html/wp-content/plugins/gutenberg/phpunit/navigation-page-test.php:73
phpvfscomposer:///var/www/html/wp-content/plugins/gutenberg/vendor/phpunit/phpunit/phpunit:97

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[ockham]

Looks like the issue is in gutenberg_resolve_assets, which hooks into block_editor_settings_all to set the __unstableResolvedAssets field. Curiously, that’s done in lib/compat/wordpress-6.0.

It seems like it’s been superseded in Core by _wp_get_iframed_editor_assets.

Immediately following questions:

• Is the issue present in Core's _wp_get_iframed_editor_assets, or has it been fixed there?
• If it's present there, we should probably add unit test coverage to catch any issues like that earlier.

[ockham]

Is the issue present in Core's _wp_get_iframed_editor_assets, or has it been fixed there?

Inspecting style_handles reveals that some entries are arrays rather than strings, e.g. no. 135 in the following snippet:

    [131] => wp-block-post-comment
    [132] => wp-block-post-comment-editor
    [133] => wp-block-post-comments-count
    [134] => wp-block-post-comments-count-editor
    [135] => Array
        (
            [0] => wp-block-post-comments-form
            [1] => wp-block-buttons
            [2] => wp-block-button
        )

    [136] => wp-block-post-comments-form-editor
    [137] => wp-block-post-comments-link
    [138] => wp-block-post-comments-link-editor

Current working hypothesis: It was probably fixed in Core, by the very PR that introduced the _handles-suffixed versions of editor_script_handles etc to allow passing arrays.

And it was probably my back-compat fix that changed the behavior of the un-suffixed editor_script fields.

I'll work on a fix shortly.

[ockham]

FWIW, here's the corresponding output for $style_handles prior to WordPress/wordpress-develop#3487:

    [131] => wp-block-post-comment
    [132] => wp-block-post-comment-editor
    [133] => wp-block-post-comments-count
    [134] => wp-block-post-comments-count-editor
    [135] => wp-block-post-comments-form
    [136] => wp-block-post-comments-form-editor
    [137] => wp-block-post-comments-link
    [138] => wp-block-post-comments-link-editor

Note that the array at 135 is flattened to its first item.

[ockham]

Before I commit to the simple solution -- picking the first array item -- I'd like to verify that that was indeed the behavior before WordPress/wordpress-develop#3108, or if we should have WP_Block_type::__get() return something different. (I've tried for a bit now, but it's late and my brain is kinda fried, so I'm not really trusting my own findings right now.)

For reference, this is the "simple solution":

diff --git a/lib/compat/wordpress-6.0/client-assets.php b/lib/compat/wordpress-6.0/client-assets.php
index 0c5697817a..9c77b089eb 100644
--- a/lib/compat/wordpress-6.0/client-assets.php
+++ b/lib/compat/wordpress-6.0/client-assets.php
@@ -61,15 +61,27 @@ function gutenberg_resolve_assets() {
 
        foreach ( $block_registry->get_all_registered() as $block_type ) {
                if ( ! empty( $block_type->style ) ) {
-                       $style_handles[] = $block_type->style;
+                       if ( is_array( $block_type->style ) ) {
+                               $style_handles[] = $block_type->style[0];
+                       } else {
+                               $style_handles[] = $block_type->style;
+                       }
                }
 
                if ( ! empty( $block_type->editor_style ) ) {
-                       $style_handles[] = $block_type->editor_style;
+                       if ( is_array( $block_type->editor_style ) ) {
+                               $style_handles[] = $block_type->editor_style[0];
+                       } else {
+                               $style_handles[] = $block_type->editor_style;
+                       }
                }
 
                if ( ! empty( $block_type->script ) ) {
-                       $script_handles[] = $block_type->script;
+                       if ( is_array( $block_type->script ) ) {
+                               $style_handles[] = $block_type->script[0];
+                       } else {
+                               $style_handles[] = $block_type->script;
+                       }
                }
        }
 

[dd32]

Just noting this also results in a fatal error on PHP8, and an obscene number of Notices/Warnings on wordpress.org/gutenberg/ :)

PHP Fatal error:  Uncaught TypeError: explode(): Argument #2 ($string) must be of type string, array given in wp-includes/class-wp-dependencies.php:188
Stack trace:
#0 wp-includes/class-wp-dependencies.php(188): explode('?', Array)
#1 wp-includes/class-wp-styles.php(371): WP_Dependencies->all_deps(Array, false, false)
#2 wp-includes/class-wp-dependencies.php(127): WP_Styles->all_deps(Array)
#3 wp-content/plugins/gutenberg/lib/compat/wordpress-6.0/client-assets.php(83): WP_Dependencies->do_items(Array)
#4 wp-content/plugins/gutenberg/lib/compat/wordpress-6.0/client-assets.php(109): gutenberg_resolve_assets()
#5 wp-includes/class-wp-hook.php(310): {closure}(Array)
#6 wp-includes/plugin.php(205): WP_Hook->apply_filters(Array, Array)
#7 wp-includes/block-editor.php(539): apply_filters('block_editor_se...', Array, Object(WP_Block_Editor_Context))
#8 wp-content/themes/wporg-gutenberg/functions.php(288): get_block_editor_settings(Array, Object(WP_Block_Editor_Context))
#9 wp-content/themes/wporg-gutenberg/functions.php(505): gutenberg_editor_scripts_and_styles('')
#10 wp-includes/class-wp-hook.php(308): {closure}('')
#11 wp-includes/class-wp-hook.php(332): WP_Hook->apply_filters(NULL, Array)
#12 wp-includes/plugin.php(517): WP_Hook->do_action(Array)
#13 wp-includes/script-loader.php(2180): do_action('wp_enqueue_scri...')
#14 wp-includes/class-wp-hook.php(308): wp_enqueue_scripts('')
#15 wp-includes/class-wp-hook.php(332): WP_Hook->apply_filters(NULL, Array)
#16 wp-includes/plugin.php(517): WP_Hook->do_action(Array)
#17 wp-includes/general-template.php(3043): do_action('wp_head')
#18 wp-includes/template-canvas.php(17): wp_head()
#19 wp-includes/template-loader.php(106): include('...')
#20 wp-blog-header.php(19): require_once('...')
#21 index.php(18): require('...')
#22 {main}
  thrown in wp-includes/class-wp-dependencies.php on line 188

[Mamaduka]

I created a PR with a straightforward fix - #45265.