Ability to save Nav blocks locally without creating a wp_navigation post.

[getdave]

What problem does this address?

Currently when creating a Navigation block a wp_navigation post is automatically created and all inner blocks are saved to that post.

It is therefore not possible to create a Navigation block that is local to a specific post context. This also means that anyone without the edit_theme_options capability cannot create Navigations even if they are only for the purpose of a single page (as opposed to global).

What is your proposed solution?

Add a means by which users an opt to save the Navigation block items locally to the current post. In such cases no Navigation Post would be created and the block would use standard uncontrolled inner blocks.

cc @spacedmonkey who has previously discussed this with me.

[word-x]

This needs to be solved. Even if we register the wp_navigation post type in function.php, it still can't be edited.
It's difficult to use.
There should be a back-end page to edit the menu without going to FSE.
Moreover, many multilanguage plugins needs to translate menu in backend.

[word-x]

Do you have a temporary way to edit the menu block code? @getdave I don't know how long it takes to get this solved. Any hint would be appreciated.

[getdave]

Do you have a temporary way to edit the menu block code? @getdave I don't know how long it takes to get this solved. Any hint would be appreciated.

@word-x I have documented a solution to accessing Navigation block inner blocks in this video. I hope that helps?

There should be a back-end page to edit the menu without going to FSE.

The menus are blocks so the best medium for editing them is in a block editor. You might like to review this Issue which tracks the need to have the ability to edit menu items in isolation.

[word-x]

Yes, I watched this video.
Actually, I am working on a translation plugin. Classic menu can be translated but the Navigation Block Menu can't be translated.
It seems that we need a hook or similar thing to translate the Navigation Block Menu.

[getdave]

Reporting a comment from @fabiankaegy:

Additionally, there were many cases in the past where the Navigation block was not just used for Global navigations, but also local in page navigations that should never be synced were possible. This no longer really is the case. Yes you can create a unique synced menu location for every instance of the navigation block you insert. But the flow for that is not ideal.

If we need all navigation menus to be synced, I think we should refine the insertion UX of the block to be more like the image, columns, group, or query block and render a placeholder first where a user can select an existing navigation menu or create a new one right then and there. That would make it much clearer for users whats actually happening :)

[getdave]

@fabiankaegy I will defer to @WordPress/gutenberg-design on this one but I don't think we want to introduce friction into the insertion experience.

We used to have an experience like that and design were very keen to guide us away from that and have the block "just work". The aim is to hide the complexity of the concept of sync'd navigations as that's not really something the user should have to care about.

I think that approach is pretty valid when you consider the 80% use case is likely to be the requirement for a synced navigation.

That's not to say I don't agree with the use case you outline. But I would like to see the mechanism for switching to unsynced be something you have to find and activate rather than something you are required to choose each time you insert a block.

Perhaps a @richtabor has an idea for how this could function. Maybe a "detach" option somewhere.

Technically, we'd have to refine the logic for the block to ensure that if a user has added the detached attribute then the block does not attempt to do any form of syncing and just uses standard uncontrolled inner blocks.

I'm curious to hear how important you feel this feature to be relative to the items currently listed on the tracking issue.

Thanks again for taking the time to provide feedback 🙇

[fabiankaegy]

Hey @getdave 👋

I think the fact that I mixed two different issues there made my comments more confusing. When I proposed the addition of the placeholder when inserting a new navigation, that had nothing to do with unsynced vs. synced navigations. I agree that is an issue that should be considered. But the issue for which I added the mockup is that I currently find it's to difficult for a user to switch between navigation menus in the navigation block. And when you insert a new navigation block today it's not obvious which menu was selected and even that it is synced. So I often run into the issue that someone inserts the navigation block and changes the items in the menu without realizing that it affects other navigation blocks also.

Because of that I very much believe that the friction we would be adding would actually be a good thing because it would allow users to understand whether they want to display an existing navigation or display a new one.

And for starters I would also expect that creasing a new one would create a new synced one. I think that issue is different from unsynced navigations

[getdave]

No worries. So you might like to advocate for #49158 and take a look at #54436.