Navigation block: If a classic menu is assigned, the menu on the front does not update

[carolinan]

Description

When using WordPress 6.2, the navigation block does not change on the front when you assign a "classic" menu (a menu created with a classic theme in the old menu screen).

Step-by-step reproduction instructions

On a fresh install of 6.2:

1. Activate a classic theme
2. Create two classic menus with different content.
3. Switch to a block theme.
4. Go to the Site Editor. Confirm that one menu of the two menus is assigned to the navigation block by default.
5. View the front, and confirm that the content of the menu is correct.
6. Return to the Site Editor and change to the other classic menu. Confirm that the navigation block in the editor is updated,.
7. View the front. Confirm that it is the content of the first menu that shows.
8. Create a new menu via the option in the navigation block sidebar.
9. Confirm that this new menu shows correctly in the editor and front.
10. Re-assign one of the two classic menus. Confirm that it is the classic menu that shows in the editor and the new "block" menu that shows on the front.

Screenshots, screen recording, code snippet

No response

Environment info

WordPress 6.2
macOS
Chrome
PHP 7.4.30
nginx

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

[carolinan]

I have had two people report that they can reproduce this with classic themes.

[Olein-jp]

I could reproduce the same. Them menu which was made in Classic Theme couldn’t be active and visible.

[cuemarie]

While testing this for Automattic/wp-calypso#75800 , I was able to replicate, but found some additional next steps that help:

• When you first import a classic menu, save, and view the live site, the newly imported menu does not appear like it does in the editor.
• However, if I return to the editor and rearrange the menu items in any way, then save again - my updated menu now appears on the live site.

Screen.Capture.on.2023-04-18.at.14-05-33.mp4

This behavior matches whether I created the Classic Menu in Appearance > Menus or in Appearance > Customize > Menus.

Testing Environment:

• WordPress 6.2
• Gutenberg Version 15.5.1 and no other plugins active
• Firefox 112.0.1
• Themes in test: Twenty Twenty, Twenty Twenty Three

[annezazu]

@scruffian @getdave mind digging into this?

[getdave]

From the video I can see that when you first import (select) the Classic menu it does not trigger the Navigation Menu to show up in the entity saving panel in the "Save" flow. All I saw was a change to the Header template part.

However, once you've made a change and click "Save", the Navigation does show up as having been changed.

From the code it looks like the Classic Menu is initially imported as a Draft. That could be relevant here.

[hartsook]

I think this bug has a secondary problem. If you have multiple navigation blocks on the same page (or Template) and select different classic menus for each block, the correct menu labels show in the editor, but on the front end all the nav blocks display whatever menu was first on the page. This is in spite of different reference numbers for the navigation block when looking at the code editor for the page.

The suggestion to edit the order of the items in a classic menu and save does fix the problem. Once saved, the proper menu items show on the back end and the front end.

[getdave]

Thank you for reporting this. We'll bear that in mind whilst investigating. Very helpful 🙇‍♂️

So folks are aware contributors are spending significant time at the moment revising and augmenting the test suite associated with the block. Each time we encounter one of these issues we add test coverage for it. Incrementing towards a more resilient block.

[drussell17]

This problem crept in somewhere in last stages of 6.2 release.
I had a working site with 6.1.1 and Gutenberg 5.3
All my test site experience this issue now.
Unfortunately I deleted the working site so I can't be more exact than that.
I'm also seeing "coded" special characters in the fall back menu that appears.

[drussell17]

I found a copy of my work in 6.1.1 in an instance where the Gutenberg plugin is disabled.
If I simply upgrade that site to 6.2 the menus work fine.
If instead I go back to my classic theme version and update to 6.2 before installing the block theme I then get the issue that @hartsook reported. But if I use @cuemarie s workaround its OK except for the fact that I have submenus and the nav block just won't let me place a top level item after an item with a submenu. Perhaps there's another bug report regarding that. Will test some more offline and look at the differences between my hosted instances and my local server.

[getdave]

Thanks for reporting and apologies for the slow response here.

Re-assign one of the two classic menus. Confirm that it is the classic menu that shows in the editor and the new "block" menu that shows on the front.

I can replicate this. From what I can tell, then import of the classic menu succeeds in creating a (Block based) Navigation Menu. However the new menu doesn't seem to trigger an entity dirty state. This means when you hit "Save" in the editor the newly imported Navigation Menu (the clone of the classic one) is not saved. Therefore it does not show on the front of the site.

I can also replicate this on trunk. Now looking into the cause...

[getdave]

The bug is that when the classic menu is converted into a (block based) Navigation Menu the call to editEntityRecord does not set the status to publish. Rather it simply sets it to whatever the initial status argument was:

gutenberg/packages/block-library/src/navigation/edit/use-convert-classic-menu-to-block-menu.js

Line 100 in 44308e7

status: postStatus,

This means that the entity never becomes "dirty" and thus never gets included in the "saved" changes when you click "Save" in the editor.

This appears to have been introduced in #43580

The clue is in the comment where it references publish as the expected state change:

gutenberg/packages/block-library/src/navigation/edit/use-convert-classic-menu-to-block-menu.js

Lines 88 to 103 in 44308e7

	/**
	* Immediately trigger editEntityRecord to change the wp_navigation post status to 'publish'.
	* This status change causes the menu to be displayed on the front of the site and sets the post state to be "dirty".
	* The problem being solved is if saveEditedEntityRecord was used here, the menu would be updated on the frontend and the editor _automatically_,
	* without user interaction.
	* If the user abandons the site editor without saving, there would still be a wp_navigation post created as draft.
	*/
	await editEntityRecord(
	'postType',
	'wp_navigation',
	navigationMenu.id,
	{
	status: postStatus,
	},
	{ throwOnError: true }
	);

The fix is to change this back to a hard coded string publish. I will spin up a PR.