[wp-trac] [WordPress Trac] #16075: Add Post Type Archives support in Nav Menus

WordPress Trac noreply at wordpress.org
Thu Oct 2 02:19:20 UTC 2014


#16075: Add Post Type Archives support in Nav Menus
---------------------------------------------+-----------------------------
 Reporter:  matzipan                         |       Owner:  wonderboymusic
     Type:  enhancement                      |      Status:  reviewing
 Priority:  normal                           |   Milestone:  Future Release
Component:  Menus                            |     Version:  3.1
 Severity:  normal                           |  Resolution:
 Keywords:  has-patch ui-feedback 4.1-early  |     Focuses:
---------------------------------------------+-----------------------------

Comment (by celloexpressions):

 I thought I left this comment a month ago, but apparently I didn't.

 There is a significant issue here with the way that this would work with
 respect to our handling of "home" and the `post` post type archive (blog
 page). If custom post types have an archive menu item that has a non-
 configurable URL and "just works", blog posts should too, instead of being
 assigned to a page like they are now. As it is now, I foresee a lot of
 confusion over why the core post types work like that but custom ones work
 like this.

 The only possibility for implementing this UI-wise without digging too far
 down that rabbit hole would be to make an "archive" item appear in each
 post type at the top in the same way that we do that for the home link in
 pages, which, upon being added, would be a custom link menu-item-type.
 This is 100% a hack, so I really don't feel good about doing it that way.
 The menus system is built off of the concept of every menu item
 representing either a post object or a taxonomy term (which is duplicated
 and extended as a post with the `menu_item` type). Different types of menu
 items (custom, post, page, tag, category, etc.) represent different types
 of objects in WordPress and "archive", in addition to having other
 meanings within WordPress, doesn't work with the existing paradigms we
 have here.

 I really don't like the idea of creating an `archive` menu item type, like
 the latest patch does. "Archive" has no useful meaning with relation to
 what that menu item represents - it really should belong to the post type
 that it's representing (and we also need to keep in mind that there are
 other types of archives, like taxonomy terms, that can be created as menu
 items). But to do that properly, we would need to have a post of each type
 that served as a placeholder for the archive, kind of like how we have a
 page that serves as a placeholder for the `post` archive (blog) when there
 is a static front page.

 A possible work-around might be to add all post type archives to "Pages",
 but again as Custom menu item types once they're added. That would work
 the best with the way we do this for posts and home right now.

 And regardless of what we do here, there is absolutely no reason to add a
 new accordion section of available menu items for "Archives", for the same
 reasons that it wouldn't make sense to have an "archive" post type or
 taxonomy.

 All of these reasons explain why we can't really resolve [comment:50] and
 [comment:51] without a significant re-thinking of how post type archives
 work in core, or some really nasty hacks. And for that reason, I'm not
 sure that we should move forward with this right now unless we are willing
 to take the time to consider these issues.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/16075#comment:75>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list