[WP6.4] Rename UI is displayed in the advanced panel of all blocks

[t-hamano]

Description

In the latest Gutenberg, rename UI is enabled for almost all blocks, but as of WordPress 6.4, only group blocks should be renameable. However, except for group blocks, there is a rename UI in the Advanced panel for almost all blocks.

If you enter a new block name in this panel, it will not be reflected in the list view. It also doesn't seem to be saved as attributes.

The rename menu is not displayed in the list view or block toolbar menu unless it is a group block.

Step-by-step reproduction instructions

• Inserts some block other than the group block.
• Open the Advanced panel and verify that the "Block Name" field is present.
• The block name in the list view should not change when you enter text.

Screenshots, screen recording, code snippet

b4cfd8596298506cf2ad2a7b0f9a6ae6.mp4

Environment info

WordPress 6.4 (General Release Version)

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

[Mamaduka]

This was introduced during refactoring in #55604. The control uses hasBlockSupport( name, 'renaming', true ); check, which doesn't ship with WP 6.4.

cc @getdave

[getdave]

That's a bug if it's happenning for 6.4. Renaming support for all blocks should be in Gutenberg trunk only.

[getdave]

Fix for this will need to land (I assume) in 6.4.1.

diff --git a/packages/block-editor/src/hooks/block-rename.js b/packages/block-editor/src/hooks/block-rename.js
index d8f414a3e9..60d13760f2 100644
--- a/packages/block-editor/src/hooks/block-rename.js
+++ b/packages/block-editor/src/hooks/block-rename.js
@@ -16,7 +16,11 @@ export const withBlockRenameControl = createHigherOrderComponent(
 	( BlockEdit ) => ( props ) => {
 		const { name, attributes, setAttributes, isSelected } = props;
 
-		const supportsBlockNaming = hasBlockSupport( name, 'renaming', true );
+		const supportsBlockNaming = hasBlockSupport(
+			name,
+			'__experimentalMetadata',
+			false
+		);
 
 		return (
 			<>

Pinging @mikachan for advice on next steps.

This happened as the result of changes in trunk becoming out of sync with 6.4.

[mikachan]

Thanks for the ping! I believe the next steps to include a fix for 6.4.1 would be to create a PR against the wp/6.4 branch with the above change and add the Backport to WP Minor Release label.

[getdave]

Thanks. Working on a PR now.

[MadtownLems]

It looks like this missed 6.4.1. Can someone confirm it's on the list for 6.4.2? A new field that does nothing (and has no explanatory text) is pretty confusing 😅

[getdave]

@mikachan Did we not land the fix in 6.4.1?

[mikachan]

This fix didn't go out with 6.4.1 as that was an emergency release for a single fix on the Core side. This fix will be going out with 6.4.2, alongside some other GB package updates: WordPress/wordpress-develop#5665

[t-hamano]

Update: WordPress 6.4.2 was released on December 6th, but this issue does not seem to be resolved. My understanding is that 6.4.2 is a maintenance security release. As stated in this core ticket, it will be fixed when 6.4.3 is released.

[mikachan]

My understanding is that 6.4.2 is a maintenance security release. As stated in this core ticket, it will be fixed when 6.4.3 is released.

This is my understanding, too 👍

[t-hamano]

Now that WordPress 6.4.3 has been released, I tested this issue again. This issue appears to have been fixed, so I would like to close it. Thank you everyone!