The current navigation menus system is built around a paradigm that every menu item must be associated with an existing piece of content. However, this is problematic for new users, who may find themselves with the opportunity to build a menu before creating any content. #34923 seeks to improve this experience and eliminate this usability “dead end” by adding the ability to create new post objects (most notably pages) within the menus interface in the customizer.
Purpose & Goals
While this feature is aimed primarily at new users setting up their site for the first time, it may also be useful for users that are restructuring a site, or even if they want to add a page here or there and add it to their menu before filling out its contents. It’s important to note that posts and pages added here are stubs – only their title is filled out, and the content will be added later via the post editor. For that reason, most existing sites would probably maintain their existing workflows to create new pages via the post editor, publish them, and then add them to menus. This is of course still fully supported and the new proposal seeks to provide an alternative approach that may be better for different use cases such as new sites.
Because the feature is proposed to be located in the customizer, it also fully supports live preview. The live preview component can build user trust and confidence by letting users preview and interact with their site as changes are made, before they’re published.
To allow new content to be created in the customizer, posts are created with the
auto_draft status. When the user saves & publishes in the customizer, these newly-created posts are transitioned to be published. In the customizer preview, the status is modified to protected to allow the posts to be previewed.
Ideally, term creation should also be a part of the menus UI. Unfortunately, terms to not currently have a status field, and implementing that or looking at alternative approaches is something that will take more thought. Thus, this feature is being built with future support for terms in mind, but without support currently.
By default, the ability to add new content depends on the appropriate capabilities and the
show_in_nav_menus parameter when registering post types. Additionally, a new filter is proposed to allow authorship in menus to be disabled on a per-post-type basis.
User testing has been requested and there are several tasks that could be tested:
- Create a new menu for a brand new site by creating pages and adding them to a menu, assign the menu to a location and publish it.
- On an existing site, create new pages to add to an existing menu.
- On a complex site with multiple menus create a new page once then add it to multiple menus.
- On sites with custom post types, create new custom posts for any of the scenarios above.
Customize Posts Plugin
Part of the inspiration for this feature comes from the Customize Posts plugin, which has the ability to live-preview posts and post meta in the customizer. Only a very small portion of the plugin would make its way into core as part of the nav menus content authorship feature. However, the proposal is currently to establish the
wp.customize.Posts namespace for future expansions of post-related functionality in the customizer. The existing plugin would extend this core namespace, and other plugins could do so as well.
There are currently no plans to consider the Customize Posts plugin for full merge into core; however, stay tuned for an upcoming feature project kick-off that will seek to explore the future of live preview in WordPress at a broader level.
Feedback & Next Steps
The latest patch is currently seeking feedback for accessibility, design, code review, docs, and general comments. Please test it and leave your feedback as comments on this post or the ticket, #34923. Given current timing the ticket is likely to target the 4.7 milestone.
One remaining piece to implement is a mechanism to inform the user that their new posts have been published and provide links to edit the posts in the admin. This could take the form of a notifications area in the customizer or preview, or happen inline within the menus UI as a notice using the customizer setting validation feature that’s new in 4.6. UX feedback and ideas for the potential approach here are needed, and it could also probably work to ship without this part for now.