Automatically add newly published pages to the navigation block

[draganescu]

Is your feature request related to a problem? Please describe.
This is a feature which exists in the current WordPress menus. If we want this block to be the cornerstone of a new and better menus page in WordPress admin (#16635) then we need to have this feature supported b/c the new menus need to behave identically.

Describe the solution you'd like
The Navigation block should support this toggle and both render and add newly published pages to its list of pages.

Note
While on the server at render time one could think of doing a diff between a list of published pages and the list in the currently rendering bloc, in the editor that would be weird as a newly added page would automatically make the post unsaved, since detecting a new page changes the contents of the Navigation block. Therefore this needs an UX discussion.

[shaunandrews]

Is this issue related to adding a switch to the block's sidebar options? Something like this:

[draganescu]

Yes that is the feature this issue is about :)

[draganescu]

I removed the Needs Design Feedback label as the UX issue mentioned in the description (sudden dirty state posts) should be avoided by implementing the Navigation block in such way that it gets automatically updated at publish time ...

[mtias]

What's the state of this? I think it still needs feedback as it's not clear:

• What should be the default.
• Whether ti should work only top-level, only sub-level, per sub-menu tree, etc.
• How much clarity there is when publishing a new page (should the post-publish panel allow you to see how your menu was updated? Inform you about it?).

[karmatosed]

I'm going to dive in here with some feedback to try and get this moving on.

What should be the default.

I think 'off' for adding new pages makes sense as default. This is because for now you have to turn on for menus, so turning on here fits an existing mental model.

Whether it should work only top-level, only sub-level, per sub-menu tree, etc.

For me, again this falls to the existing model as that only does top level. I think only being top level makes a lot of sense as a starting point also.

How much clarity there is when publishing a new page (should the post-publish panel allow you to see how your menu was updated? Inform you about it?).

I think this could be useful information. My suggestion would be something like this as an added note:

This could go a little further by showing menus / linking to it, however, I think a gentle note is a great frst step.

[mtias]

I think only being top level makes a lot of sense as a starting point also.

I disagree. I can count a lot more examples where I might have orphaned top level pages I don't want displayed in a menu compared to sub-pages. When adding a page that has sub-pages attached, I more often expect that those show up automatically, and then any new page I create as a child of it to be reflected in the menu so I don't need to manage parent / child in two places.

My suggestion would be something like this as an added note

This seems super invisible to me. I was thinking something a lot more clear and ideally actionable — a link to the menu, a way to preview it, etc.

[karmatosed]

Here are 3 options to try and narrow down what may or may not be the right approach here. The copy definitely needs working on to go with this, just trying there.

[joanrho]

@karmatosed I think your first direction works the best in cases where the toggle to "Automatically add new top-level pages", as in @shaunandrews ' mockup above, is switched on. The second and third options feel a bit more like warning/error notices.

Just riffing on yours and Shaun's ideas: it might be helpful to explain what users can expect to happen when publishing a page when that toggle is switched on for that nav block. For example, perhaps we can show two states of that "Menu location" or whatever we want to call it in the component panel:

When toggle to "Automatically add new top-level pages" is switched ON:

• Explain what users can expect (where page will live and in which menu)
• Option to edit the menu
• Option to change the menu location (perhaps the wording could be improved on this to specific which menu users would like the page to appear in)
• Option to hide page from menus (could be useful for users who have the toggle set to "on" but don't necessarily want that page to get added to a menu—e.g., a site's legal footer links)

When toggle to "Automatically add new top-level pages" is switched OFF:

• Explain what users can expect (that page will not get auto-added to any menu)
• Option to add page to a menu

Another idea that came to mind while I was exploring the Nav block's Navigation Structure pane was introducing that same tree architecture in the pre-publish panel. That way we're not introducing new/different patterns that accomplish the same thing. Something like this, where the new page gets added to the site architecture and can be moved around:

The current menu structure interface at /wp-admin/nav-menus.php allows for dragging and dropping of items—could that also be possible for a direction like the above in both the Nav block's Navigation Structure pane and the pre-publish panel, too?

[draganescu]

@joanrho love the explorations. A couple of things to mention:

• in FSE the concept of menu location will not exist anymore
• there might be multiple menus that have the "auto add" setting set to ON, hence the sidebar of a page would have to contain all of them? Or would a user pick?

[karmatosed]

Thanks for the ideas @joanrho. The idea is yes this is an automatic process so I think adding weight at the end of the publishing flow probably for now should be avoided with the block navigator.

My feeling is if you don't add that auto, it doesn't add and for now I think that's ok. I don't think you need to then have that complexity in publishing. I am not saying we don't do this at some point, the focus now is on automatically doing this so I feel we should make that work first.

As shown in the first round of message blocks, just showing this is happening feels lighter to me. To that point, which of those do you feel is we can spring from?

Next steps I feel:

• Add a toggle as agreed.
• Work out which message style from the examples. Specifically: Automatically add newly published pages to the navigation block #16635 (comment) or your explorations here: https://user-images.githubusercontent.com/204742/77496396-8221b280-6e10-11ea-91db-a98ec74f3a95.png

I don't mind which for the visual but feel we should focus on that first.

Once we've done that another issue could absolutely explore next steps like assigning navigation on publish and another about exploring if there is an off-state needed. I feel we need to focus on this first though, then work out if that flow is desirable.

[karmatosed]

@draganescu pulling this point out as I think this is important to explore outside the mocks:

there might be multiple menus that have the "auto add" setting set to ON, hence the sidebar of a page would have to contain all of them? Or would a user pick?

A starting version for me would be to have this just add to any with the setting. However, there is then going to be some refinement needed.

This also plays into that:

I can count a lot more examples where I might have orphaned top level pages I don't want displayed in a menu compared to sub-pages. When adding a page that has sub-pages attached, I more often expect that those show up automatically, and then any new page I create as a child of it to be reflected in the menu so I don't need to manage parent / child in two places.

Working out what is expected, what will be confusing, that's some refinement I think we can build up.

[draganescu]

I've been thinking of this from an implementation perspective and there are only two ways I found to have this work for the Navigation block if we use block storage (inline HTML + comment meta).

1. Scan wp_posts for <!-- wp:navigation ... /> and alter block meta to add the new page. Seems like something very weird to do and prone to disasters that would break posts. To avoid string difficulties we could maybe do a parse of the post and a rebuild of sorts. That could work at page publish time.

In a FSE environment menus would probably be in wp_template_part and less or non in normal posts or other CPTs. That means the set of updates would be small enough to not make page publishing slow.

2. On the fly render/edit update. When we render or edit the navigation block diff the pages already in the menu and the database ones that match criteria (are top level for example), then add new menu item for each item in the diff.

The problems I see with this implementation are that we can't tell in what menu a page will end up (as pictured in the mockups above) and that when editing the block will be edited and the post type will have to be saved.

@mtias can you think of anything else here? Again, this is only if we store navigation blocks like normal blocks in post content. If we decide to, for example, save it as it's own kind of CPT or save it as a wp_block cpt, then it's a different story.

[noisysocks]

@draganescu: How do classic menus in WordPress accomplish this?

[draganescu]

hey @noisysocks

Menus in WordPress manage an option called nav_menu_options. Inside this option there is a list of menu IDs called auto_add. This list is updated when a menu's Automatically add setting is set to on by a user.

Then, transition_post_status is an action called when a post changes status. In default filters is is set to call a function _wp_auto_add_pages_to_menu. So, when a page moves to publish status this default action will use wp_update_nav_menu_item to add the new page to the menus in nav_menu_options -> auto_add list.

This system, compared to block storage (attributes in post content), has some things going for it:

• we can easily add and remove menu items because all are stored individually and share a menu ID value to establish relationship to menu
• we can store that list of menus that should be updated, because those menus have identifiers.

Without analyzing, I guess to achieve something similar we could store navigation as a wp_block post type and use the ID of these posts to hook into the options system. Updating the menus would still require more work than just inserting a menu item in a DB table, but at least we'd know exactly which menus need to be updated, and not need to search for them.

[draganescu]

Yes, so a decent solution could be to convert a Navigation block to a reusable block when the Add new top level pages automatically is checked, or to create navigation blocks are reusable blocks by default.

Creating Navigation blocks as reusable blocks by default also ties in nicely with the fact that current menus have "names" and so do reusable blocks. The we can also reference these blocks in the database directly by the postId of the wp_block.

[draganescu]

Except that #18560 has to be fixed first!

[draganescu]

After a brief chat with @mtias it appears the best path forward to be using the template_part post type as the best solution for indentifying a menu for edit. Instead of wp_block which is the CPT for reusable blocks, we can save navigation blocks as template_part CPT.

This will allow us to identify a menu by id, keep a list of menus that should be automatically updated and also edit automatically only menu content. However, saving menus as template_part CPT opens up two new features the navigation block should have:

1. A name - this block should have a name from which we can generate a slug so we can save the CPT and with which we can identify the block later for reuse

2. A way to create from the saved Navigation blocks (getting them from the template_part CPT ).

This brings a new option to the placeholder, create from existing Navigation. While #18869 creates from existing classic WordPress menus, we'll also need a way to create from existing Navigation block menus. This might mean that we move to "Import a classic menu" or something similar.

[tellthemachines]

Is there anything in this issue that wasn't covered in #27130? If not, can it be closed now?

[draganescu]

Well the feature itself does not exist yet for the standalone block. I think that this issue will be closed by having:

a) a pages block that allows newly published pages to be automatically added
b) the certainty that this is enough to close this issue

[shaunandrews]

My assumption is that having the Pages block (outlined in #23689) will mostly resolve this, albeit in a limited way. You'll be able to use the Pages block and show all pages, keeping things in sync all around — or, create a bespoke collection of Link blocks.

I expect that the new Pages block could grow to allow more granular control over what pages are shown, which opens to door to more flexibility.

[jasmussen]

I would definitely say the Page List block fixes this issue. I would consider it the way to keep menus in sync, and as soon as you "detach" the page list and convert it to individual menu items, then it's a customized menu.

[tellthemachines]

Closing this as #28265, which adds a self-updating Page list block, has been merged.