Plugin: viewScript does not work with multiple handles/files

[rufus87]

Description

During block type registration from metadata ( register_block_type_from_metadata function ) there is a great possibility to edit block metadata as it passes threw $metadata = apply_filters( 'block_type_metadata', $metadata ); filter. However there is a callback hooked in block_type_metadata filter in gutenberg plugin which registers all scripts ( handles or files ) but actually returns only the first handle name as the value of viewScript key in metadata array.

Step-by-step reproduction instructions

1. Add more than one handles as a value of viewScript key in any block.json file:

{ ... "viewScript": ["file:./slider.min.js", "file:./view.min.js"], }

the result should be
[ ... 'viewScript' => ['slider-handle-name', 'view-handle-name'] ]

the actual result is
[ ... 'viewScript' => 'slider-handle-name' ]

View script never contains an array of handle name, even if block.json does.

Screenshots, screen recording, code snippet

The above screenshot shows how is it implemented in current 14.5.3 version.

Environment info

• WP v6.1.1
• Google Chrome Version 107.0.5304.107 (Official Build) (64-bit)
• Desktop with Windows 11

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

[t-hamano]

Thanks for the report.

I think this is due to the handling of paths in Windows. I recently had a similar problem with a navigation block that has two viewScript, but this was resolved in #45773.

This is included in Gutenberg 14.7 but has not yet been released as a plugin. If you can build the latest trunk, I believe this issue has been resolved.

[rufus87]

@t-hamano , probably your issue is fixed, but the one described in this ticker still is not. Please refer to the screenshot. The trunk branch in the repository right now contain exactly same code as shown in the screenshot. The issue is still actual

[t-hamano]

@rufus87
You're right,
When the Gutenberg plugin is enabled, it appears that multiple viewScripts are only available in the core block.

gutenberg/lib/compat/wordpress-6.1/blocks.php

Line 74 in 8795c6e

! str_starts_with( $metadata['file'], wp_normalize_path( gutenberg_dir_path() ) )

@aristath
I have found that you were the first to implement this feature in #36176. Should this feature be applied to other than core blocks?

[aristath]

Hmmm the implementation was refactored in Core (see https://core.trac.wordpress.org/ticket/56408#no0), but from what I can tell here, the changes were not backported to Gutenberg.
Perhaps this should be moved to the 6.0-compat folder instead of the 6.1? 🤔

[t-hamano]

Thanks for the information, @aristath.

I looked into it, but I couldn't figure out if we should move it to the wordpress-6.0 folder or if we should backport the core changes to Gutenberg 😅

For now, I would like to add the Needs Technical Feedback label.

[dd32]

This caused some problems on WordPress.org, I suspect either:

• gutenberg_block_type_metadata_multiple_view_scripts() should be gated to only run on WordPress < 6.1
• gutenberg_block_type_metadata_multiple_view_scripts() should only run on scripts that are core blocks, as done in gutenberg_block_type_metadata_view_script(). (Submitting PR)

Even if changes were made in core that were not back-ported to Gutenberg, this breakage seems to be clearly a bug in the Gutenberg filter.

[gziolo]

Hmmm the implementation was refactored in Core (see https://core.trac.wordpress.org/ticket/56408#no0), but from what I can tell here, the changes were not backported to Gutenberg.
Perhaps this should be moved to the 6.0-compat folder instead of the 6.1? 🤔

Good catch. I think we should move it to a different folder and prevent it from running in WordPress 6.1 and higher. The idea was that the plugin continues to work when a block defines an array but and older version of WordPress core expects a string.

By the way, we might go also with an alternative approach and set the minimum version of WordPress to 6.1 as it seems to be good timing with WP 6.2 planned for the end of this month.