Navigation block: Change how we create classic menus

[scruffian]

What problem does this address?

When you create a new navigation menu from a classic menu then a new wp_navigation CPT is created, which is already populated with the content of the classic navigation. The upshot of this is that as soon as the classic navigation is created the fallback behaviour of the block is changed and the classic menu is used instead of page list (as described in #42799)

What is your proposed solution?

There are two potential solutions:

1. Create the classic navigation as a "draft" CPT.
I tried this approach, simply changing the status of the record from "published" to "draft" when the CPT is created (in use-create-navigation-menu.js). This does change the new CPTs to be draft, but the post doesn't get marked as dirty in the entity saving flow. We would need to update the enitity saving flow to understand draft posts. I don't know how complex this would be.

2. Create the classic menu empty and then replace inner blocks with the classic navigation items
Alternatively we could create the new "classic" wp_navigation CPT empty (which is what happens when you create a new navigation menu normally), and then populate the inner blocks with the navigation items that were returned from the API. This should mark the block as "dirty" for the entity saving flow, so it feels like it should be a simpler approach. I made a start here: #43190

[talldan]

This does change the new CPTs to be draft, but the post doesn't get marked as dirty in the entity saving flow. We would need to update the enitity saving flow to understand draft posts. I don't know how complex this would be.

@scruffian I have an idea. You could create the menu as a draft, but immediately trigger editEntityRecord to change the post status to 'publish'. The status change would hopefully cause it to be dirty.

Personally I feel like that's a nicer approach compared to #43190, part of something being a draft is that it's not publicly visible so it's sort of using the right semantics. There may be a couple of other things to tackle. There are a couple of places that reference the 'publish' status status for the nav block that might cause drafts not to work as expected:

gutenberg/packages/block-library/src/navigation/use-navigation-menu.js

Line 71 in 1a83ae7

{ per_page: -1, status: 'publish' },

gutenberg/packages/block-library/src/navigation/use-navigation-menu.js

Line 105 in 1a83ae7

const isNavigationMenuPublished = editedNavigationMenu.status === 'publish';

[cbravobernal]

@scruffian I have an idea. You could create the menu as a draft, but immediately trigger editEntityRecord to change the post status to 'publish'. The status change would hopefully cause it to be dirty.

This solution seems to be working but, also, creates duplicated navigation menus that could last forever on the DB (I cannot find an easy way to get to navigation menus as a user).

I will keep you updated!

[getdave]

the fallback behaviour of the block is changed and the classic menu is used instead of page list

I don't fully follow this. So you're saying as a user you've clicked on one of the classic menus. The code has run the conversion to a block menu and then updated the block.

What's the problem? How does this manifest for the user?

[cbravobernal]

What's the problem? How does this manifest for the user?

I guess the problem here is that change (conversion from page list to block elements menu) happens automatically (which is cool) but also is autosaved.
Meaning that if the user reloads the page without saving or closes the tab, if he reloads the main site or goes back to the editor, they will see the changes applied (new custom menu) like if they had clicked on the "save" button.

[scruffian]

What's the problem? How does this manifest for the user?

The behaviour for creating a new menu and importing a classic menu are inconsistent. If I create a new menu, but don't save my changes, the front of the site is unchanged. If I import a classic menu then the frontend of the site is changed immediately without me saving anything.

[cbravobernal]

@scruffian I have an idea. You could create the menu as a draft, but immediately trigger editEntityRecord to change the post status to 'publish'. The status change would hopefully cause it to be dirty.

I tried @talldan 's idea in #43580, it works, but it may cause duplicated draft menus.

[getdave]

The behaviour for creating a new menu and importing a classic menu are inconsistent. If I create a new menu, but don't save my changes, the front of the site is unchanged. If I import a classic menu then the frontend of the site is changed immediately without me saving anything.

This is a really clear explanation of the problem. Thank you.

Now my question is what makes that behaviour inconsistent? What specific process occurs that makes one different from the other?

[cbravobernal]

Now my question is what makes that behavior inconsistent? What specific process occurs that makes one different from the other?

The specific difference between those two processes is that creating a new menu starts with one empty (so then the frontend shows the fallback (page list) and the editor shows an empty navigation menu. And importing a classic menu creates one with content. In this last case, the frontend has a published menu with content (so it shows) and the editor also shows the menu with its content.

Possible solutions could be:

• Create all nav menus as drafts, and check if we still need the conditional on the frontend for not showing empty menus is still required (or we can just leave it to not show draft menus). Check that the user flow is working and we don't break backward compatibility
• Land this PR and have both cases, the logic from new empty published menus and classic drafted menus not being shown.

In both cases, we need to force the site editor on load to become dirty to allow the user to publish draft menus, or think about a better flow for this approach.