Summary

As we rely more on custom post types to structure site content for our themes here at BU, we're also discovering that having the primary navigation tied to pages - and just pages - is a huge limiting factor in our ability to create easy to use websites. For example, we often create a Degree Programs post type. Not being able to have the degree program live in the navigation, among other pages, means we have to develop complicated workarounds to query those programs and show them in a "faux" navigation that just doesn't play nice with everything else. Wheelock is a good example of this.

Additionally, we lack support for the Customizer. The length and number of items in a primary navigation is key to a positive mobile experience. There is no preview in BU Navigation to help test this. Customizer support would allow site editors to preview their menu changes in real time, at different device widths, and react accordingly.

Why not just use WordPress menus?

There is a lot to love about WordPress menus. They come with Customizer support built-in, you can add just about anything you want to them, and they're super flexible. However, the primary navigation is special. There are some important UX principles to consider with this kind of menu that make me think it deserves a special BU Navigation treatment, whether we use WordPress menus as a new base or not.

Primary navigation shouldn't change dramatically often. A user needs consistency when visiting websites. It should not be intermingled with other menus, where it can easily be switched in or out with, say, a social media menu.
Primary navigation is large. There is a lot of it. This calls for an expanded user interface for editing that WordPress menus does not accommodate. A user needs to be able to see the full navigation for the website and understand where things are.
Primary navigation should only print up to two levels of navigation when it is in the main navigation area, but it should be able to be nested farther than that.
Primary navigation shouldn't have EVERYTHING. Social media doesn't belong up there. Generally, posts don't either. We need some control over what types of content go in the primary navigation. WordPress menus are a free for all.
There is no "show/hide in navigation" option, and WordPress menus do not give context as to whether or not access is restricted.
We do still use section and adaptive navigation types in the content navigation widget. WordPress Menus don't have (as far as I know) a straightforward way of changing the view of the nav based on where you are in the site.
Responsive Framework relies on primary navigation. We don't want to rewrite this to switch to WordPress menus.

Requirements

Add custom post type support

[ ] The primary navigation is its own special menu. It is in a place in the UI that is unattached to any specific post type, such as pages.
[ ] The primary navigation UI allows the user to see and understand the full site navigation easily, including nesting.
[ ] The primary navigation supports adding custom post types, and allowing multiple custom post types to intermingle in the same navigation.
[ ] By default, the primary navigation only supports pages. A settings page controls which additional post types are supported. For example, if profiles are present, there should be a checkbox which allows profiles in the navigation, which should be unchecked/off by default.
[ ] Posts should never be allowed in the primary navigation.
[ ] The current behavior of showing all pages in the primary navigation UI, and not having to add them manually, should extend to any custom post type which is enabled in the Primary Navigation.
[ ] The primary navigation UI allows the user to show or hide an item in navigation directly from the UI page, without editing the original page or post.
[ ] The primary navigation continues to have support for outputting the number of levels of nesting of your choice. However, by default, it should print the first and second levels of navigation only.

Add customizer support

[ ] The primary navigation can be edited through the customizer, and changes to the navigation are reflected in the customizer preview before publishing.

Nice to haves

[ ] The primary navigation UI allows the user to search for an existing page in the navigation, and shows matching pages in the navigation tree when they are found.
[ ] Unique CSS classes for each level of navigation (Ashley can help with this).
[ ] The ability to add and output meta information, such as a CSS class, image, or short description.
[ ] An action hook inside of each <li>

Questions

[ ] We have a separate site map plugin. However, it probably only accounts for pages. Given that this plugin's goal is to produce a consistent primary site navigation, should we add an automatically generated sitemap as a feature of this plugin? My thinking is yes. Submitting sitemaps to Google for indexing is really unintuitive right now.

bu-ist / bu-navigation

Modernize BU Navigation: Allow custom post types, customizer support, in primary navigation #57