Provide a way to manage wp_navigation posts from wp-admin

[talldan]

What problem does this address?

#35746 introduced a new wp_navigation post type for storing navigation block data.

As a user when creating these new posts via the navigation menu block, one may end up with many menus from testing, tweking and trying. Then the selection of one menu becomes cumbersome as it is from a huge list. All the same, if any of the explorations around making pattern UX better resultsin autosaving navigation posts, it's even easier to end up with things like 20 draft menus.

It'd be great to have a way to manage these posts from WordPress admin. Particularly to delete a menu, without a specialized UI a user would have to assign a menu to a navigation block only to delete it.

Enabling the normal CPT wp-admin UI can actually be enabled by toggling show_ui in the CPT's definition from false to true:
https://github.com/WordPress/gutenberg/blob/trunk/lib/navigation.php#L421

But this then enables the post editor for each menu, which unfortunately doesn't work. One cannot edit the menu contents in the editor box. Fixing that, or finding another solution (isolated editing) may be a longer, later task.

I tried removing 'editor' support for the CPT:
https://github.com/WordPress/gutenberg/blob/trunk/lib/navigation.php#L430

This actually works great in terms of the UI, a user can edit some parts of menus but not the content. Unfortunately, it has an unwanted side effect. The REST API now won't save post content for wp_navigation, which is kind of a critical feature!

It seems the REST API CPT support assumes a 1 to 1 tie between showing some CPT UI and the data management available for that.

What is your proposed solution?

That's what we need, a proposed solution. Is there a way to remove 'editor' support but maintain post content support in the REST API?

We could:

• add a separate endpoint for wp_navigation that bypasses the 'editor' check, but it might be overkill.
• add another flag to the CPT definition for this particular situation
• update how 'editor' support for the CPT works, but what backwards compatibility will this break? A lot probably?

Alternatively, maybe there's a small tweak we can make to core to support this.

[anton-vlasenko]

@draganescu @talldan
The way I understand this issue is the following:

1. We should disable the post editor for each menu because it doesn't work with menus when we enable the show ui flag.
2. We still have to allow to manage menus via the All Navigation Menus page. Please see the screenshot below.
3. We should allow editing menus' content in the editor (as if the 'editor' support is enabled).

Please let me know if I got it wrong.

P.S. I am inclined to believe that we need a custom flag in the CPT settings to achieve all of that.
I will try to implement a draft PR to see if this approach works.

[talldan]

We should allow editing menus' content in the editor (as if the 'editor' support is enabled).

@anton-vlasenko I would amend this to "we should allow saving menus' content via the REST API (as if the 'editor' support is enabled)."

And then it sounds like you have the right understanding 👍

[spacedmonkey]

Does this change need to be in WordPress 5.9?

[anton-vlasenko]

@spacedmonkey

Does this change need to be in WordPress 5.9?

It doesn't have to be in WordPress 5.9.
But It depends on the fix itself.
If the fix is simple enough and suits us, it would be nice to have it in WordPress 5.9.
If the fix is not simple, it can land in WordPress later.
Alternatively, we hope to have block menus editable in the isolated template editor.

[word-x]

@talldan will this be fixed in wordpress 6.1? We tried 6.04. It still the same that Navigatioin menu can't be edited either in Block editor or in classic textarea.

[talldan]

@word-x The issue is closed, there are no changes in WordPress 6.1. For 6.1 menu editing will still take place in the site editor. I realise the Manage Menus feature is a bit limited, it was mostly included to provide an easier way to delete menus.

There is a separate issue for tracking editing menus. It's currently planned for 6.2. You can see an overview of what's planned for the navigation block in this tracking issue.

[word-x]

Thanks. Could you give us a hint on how to enable the editing (post content textarea ) of wp_navigation type? We need to have a temporary way to do that. Such as a hook in function.php.

[talldan]

@word-x This is the code that disables it:

add_action( 'edit_form_after_title', '_disable_content_editor_for_navigation_post_type' );

function _disable_content_editor_for_navigation_post_type( $post ) {
   $post_type = get_post_type( $post );
   if ( 'wp_navigation' !== $post_type ) {
   	return;
   }

   remove_post_type_support( $post_type, 'editor' );
}

You should be able to reverse this by adding similar code but calling add_post_type_support instead of remove_post_type_support.

Note that the editor probably won't work properly. Editing in the code editor mode would be your best option.

[word-x]

Thanks for your help.