WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 11 days ago

#16075 reviewing enhancement

Add Post Type Archives support in Nav Menus

Reported by: matzipan Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.1
Component: Menus Keywords: has-patch ui-feedback
Focuses: Cc:

Description

The setup: Take a post type (be it default or custom, in my case custom)

I wish to be able to add the archive page to the menu without adding the menu entry as hardcoded link (in my case /artists/)

The problem: Adding it as hardcoded link does not bring the page up as current page in the menu when visiting the link.

Example:
http://www.blowmeup.ro/artists/ vs http://www.blowmeup.ro/crews/

Attachments (10)

16075_fase1.patch (11.3 KB) - added by raulillana 4 years ago.
only post type archives implemented in fase1
16075.diff (4.0 KB) - added by aaroncampbell 4 years ago.
16075-just-filter.diff (795 bytes) - added by aaroncampbell 4 years ago.
16075.2.diff (3.7 KB) - added by aaroncampbell 4 years ago.
16075.2-refresh.diff (3.5 KB) - added by DrewAPicture 2 years ago.
16075.3.diff (3.5 KB) - added by DrewAPicture 2 years ago.
post_parent
16075.4.diff (3.5 KB) - added by DrewAPicture 2 years ago.
Refresh
16075.5.diff (5.9 KB) - added by ericlewis 2 years ago.
Fixes issues brought up in comment 50. Works properly with default permalinks as well as custom. In the menus admin screen, the CPT archive is now marked as "Archive," a new menu item type. Current menu item is set when on either an archives page for the post type or a single CPT page.
16075-refresh.diff (6.6 KB) - added by paulwilde 16 months ago.
16075-hlashbrooke.diff (5.1 KB) - added by hlashbrooke 11 days ago.
Details explained in previous comment.

Download all attachments as: .zip

Change History (96)

comment:1 @matzipan4 years ago

  • Cc matzipan added

comment:2 in reply to: ↑ description @matzipan4 years ago

It seems the same problem applies to taxonomies (these being added without hardcoded entry)

comment:3 @nacin4 years ago

  • Milestone changed from Awaiting Review to Future Release
  • Type changed from feature request to enhancement

There might be a duplicate of this ticket somewhere.

comment:4 @johnbillion4 years ago

  • Cc johnbillion@… added
  • Keywords nav menus post type archive registered entry removed

comment:5 @raulillana4 years ago

  • Cc raulillana added

comment:6 @travisnorthcutt4 years ago

  • Cc travis@… added
  • Keywords needs-patch added

I wish to be able to add the archive page to the menu without adding the menu entry as hardcoded link (in my case /artists/)

Someone correct me if I'm wrong, but I believe adding the archive page to the menu as a hardcoded link (http://site.com/post-type) does apply the expected current-menu-item class. However, adding the archive page as a relative link (/post-type) does not. Semantics, I know, but worth mentioning.

That being said, I agree that there's a need for a metabox on the menu page that would allow adding custom post type archives to a menu, and would cause the appropriate classes to be added.

comment:7 @raulillana4 years ago

Woking on this actually, dealing with the walker.

Someone more on this?

comment:8 @raulillana4 years ago

  • Keywords has-patch dev-feedback needs-testing added

comment:9 @dd324 years ago

  • Keywords needs-patch removed

What's the go with the foreach loop in wp_nav_menu_post_type_archives_meta_box()?

comment:10 @raulillana4 years ago

Oops! Testing purposes only. Correcting and re-uploading in a bit.

@raulillana4 years ago

only post type archives implemented in fase1

comment:11 @raulillana4 years ago

  • Keywords 3.2-early added
  • Owner changed from matzipan to raulillana
  • Status changed from new to assigned
  • Summary changed from Post type archive registered as entry in nav menus to Add Post Type Archives support in Nav Menus

comment:12 @johnbillion4 years ago

  • Cc johnbillion@… removed

comment:13 @johnbillion4 years ago

  • Cc johnbillion@… added

@aaroncampbell4 years ago

comment:14 @aaroncampbell4 years ago

I accidentally opened #17463 because my search for "has_archive" on here didn't return this ticket.

The patch I just attached will make everything automatic. If a post type is added and "has_archive" then the archive link checkbox will show. You can optionally include a items_archive label to be used.

I'm wondering if we could at least add a filter to 3.2 which could allow a plugin to handle this until this fix can be added?

comment:15 @aaroncampbell4 years ago

That latest patch just adds a single filter nav_menu_items_{$post_type_name}. That's what I'd like to see make 3.2. It seems like an area that plugins should have control over but don't. Ultimately I'd like to see the filter stay in (obviously) but still see the other patch use as well to make the archive bits work automagically.

comment:16 @mau4 years ago

  • Cc ngomau@… added

comment:17 @markjaquith4 years ago

I have no objection to that filter.

comment:18 @aaroncampbell4 years ago

  • Keywords dev-feedback needs-testing 3.2-early removed
  • Milestone changed from Future Release to 3.2

Moving this to 3.2 to get the filter added.

comment:19 @markjaquith4 years ago

In [17951]:

Add a per-post-type nav menu items filter for plugin control. props aaroncampbell. see #16075

@aaroncampbell4 years ago

comment:20 @aaroncampbell4 years ago

  • Keywords 3.3-early added
  • Milestone changed from 3.2 to Future Release

Refreshed patch for trunk. I'm going to move this back to "future release" and try to get it into 3.3 since it would still be nice to have the "archives" option appear and work automatically.

comment:21 follow-up: @travisnorthcutt4 years ago

Would it be viable to get at least some form of this in 3.2, and expand on it for 3.3?

comment:22 in reply to: ↑ 21 @aaroncampbell4 years ago

Replying to travisnorthcutt:

Would it be viable to get at least some form of this in 3.2, and expand on it for 3.3?

We did. We added a filter in [17951] that would let a plugin do this exact thing. I'll release the plugin before 3.2 comes out (maybe this weekend if I get time).

comment:23 @aaroncampbell4 years ago

The plugin is currently on github: Custom Post Type Archives in Nav Menus. When it's approved I'll add it to extend as well (Custom Post Type Archives in Nav Menus)

Version 0, edited 4 years ago by aaroncampbell (next)

comment:24 @travisnorthcutt4 years ago

That's fantastic. Thanks for doing this!

comment:25 follow-up: @aaroncampbell4 years ago

The plugin is in the wp.org repository now: Custom Post Type Archives in Nav Menus

comment:26 @raulillana4 years ago

Kudos! Works like a charm. :)

comment:27 @WraithKenny4 years ago

It'd be nice to have _wp_menu_item_classes_by_context assign some classes (like current-item-in-archive, current-archive-ancestor or some-such label consistent with existing ones) to the archive menu item if the currently viewed item is in that archive.

comment:28 @WraithKenny4 years ago

  • Cc Ken@… added

Maybe give the archive menu item and it's menu parents the current-menu-parent and current-menu-ancestor classes? Just an idea.

comment:29 in reply to: ↑ 25 ; follow-up: @raulillana4 years ago

Replying to aaroncampbell:

The plugin is in the wp.org repository now: Custom Post Type Archives in Nav Menus

Stopped working on 3.2

Take a look, please. ;)

comment:30 in reply to: ↑ 29 @aaroncampbell4 years ago

Replying to raulillana:

Replying to aaroncampbell:

The plugin is in the wp.org repository now: Custom Post Type Archives in Nav Menus

Stopped working on 3.2

Take a look, please. ;)

This is not the place for plugin support.

comment:31 @travisnorthcutt3 years ago

  • Keywords 3.3-early removed

Any chance of this getting into core for 3.4?

comment:32 @toscho3 years ago

  • Cc info@… added

comment:33 @maorb3 years ago

  • Cc maor@… added

+1 for getting this into core.

comment:34 @wpsmith3 years ago

  • Cc travis@… added

comment:35 @sscovil3 years ago

I agree. +1 for getting this into core.

comment:36 @aaroncampbell3 years ago

  • Cc aaroncampbell added

comment:37 @jkudish2 years ago

  • Cc jkudish added

comment:38 @husobj2 years ago

  • Cc ben@… added

comment:39 @Marco_Teethgrinder2 years ago

  • Cc marco@… added

comment:40 @rfair4042 years ago

  • Cc rfair404 added

comment:41 follow-up: @rfair4042 years ago

Is the purpose of the filter in [17951] to allow plugin authors to control the archive title beyond the args supplied when registering the actual post type?

comment:42 in reply to: ↑ 41 @aaroncampbell2 years ago

Replying to rfair404:

Is the purpose of the filter in [17951] to allow plugin authors to control the archive title beyond the args supplied when registering the actual post type?

Actually, I asked to have it added to allow you to add menu items to the list, but put it there so you could also edit them (bonus!). Take a look at the plugin I made using it (referenced above):
https://github.com/OpenRange/Custom-Post-Type-Archives-in-Nav-Menus/blob/master/cpt-archives-in-nav-menus.php

comment:43 @DrewAPicture2 years ago

  • Cc xoodrew@… added
  • Keywords needs-refresh added

comment:44 @DrewAPicture2 years ago

  • Keywords needs-refresh removed

comment:45 @DrewAPicture2 years ago

  • Keywords 3.6-menus added
  • Milestone changed from Future Release to 3.6

@DrewAPicture2 years ago

post_parent

comment:46 @DrewAPicture2 years ago

16075.3.diff fixes a notice generated for hierarchical post types.

Last edited 2 years ago by DrewAPicture (previous) (diff)

comment:47 @DrewAPicture2 years ago

  • Keywords needs-testing added

comment:48 @sabreuse2 years ago

tested the .3 patch -- looks good and works as expected for me.

@DrewAPicture2 years ago

Refresh

comment:49 @DrewAPicture2 years ago

  • Keywords needs-testing removed

comment:50 @Frank Klein2 years ago

  • Cc Frank Klein added

I tested the most recent patch, and here are the issues I ran into:

  • With the permalinks settings on default, the link of the custom post type archive doesn't work, as it relies on the slug.
  • After enabling a common setting for the permalinks, the link to the CPT archive worked and the menu item had the current-menu-item CSS class added to it. However on the single page of the CPT, there were no parent or ancestor classes added to the menu item.
  • On the Menus screen in the admin, the link to the CPT archive is marked as "custom", it should have another label.

comment:51 @DrewAPicture2 years ago

  • Keywords 3.6-menus removed
  • Milestone changed from 3.6 to Future Release
  • Owner raulillana deleted

Moving this to Future Release unless somebody else wants to pick up the ball. As it stands:

  • There's still outstanding issues as outlined in comment:50
  • No consensus on whether these links qualify as "custom" or "page" links
  • No consensus on whether these links belong in the post type meta boxes

@ericlewis2 years ago

Fixes issues brought up in comment 50. Works properly with default permalinks as well as custom. In the menus admin screen, the CPT archive is now marked as "Archive," a new menu item type. Current menu item is set when on either an archives page for the post type or a single CPT page.

comment:52 @DrewAPicture2 years ago

  • Milestone changed from Future Release to Awaiting Review

comment:53 @ericlewis2 years ago

  • Keywords ui-feedback added

This could use a glance as far as UI is concerned.

In the menu editor, the placement of "Post Archives" exclusively under the "All Posts" tab doesn't feel completely natural to me. Perhaps with some minor styling (padding, font styling) it would look like it belongs more.

comment:54 @emzo2 years ago

  • Cc wordpress@… added

comment:55 @mfields2 years ago

  • Cc michael@… added

comment:56 @mtekk2 years ago

  • Cc mtekkmonkey@… added

comment:57 @alexvorn223 months ago

  • Cc alexvornoffice@… added
  • Severity changed from normal to major

comment:58 @aaroncampbell23 months ago

  • Severity changed from major to normal

comment:59 @c3mdigital22 months ago

  • Keywords needs-refresh added

comment:60 @Frank Klein17 months ago

  • Cc contact@… added

@paulwilde16 months ago

comment:61 @paulwilde16 months ago

  • Keywords needs-refresh removed

Refreshed ericlewis' patch to work with trunk.

comment:62 @helen15 months ago

#27396 was marked as a duplicate.

comment:63 @GermanKiwi10 months ago

Hi all, just wondering what is the current status of this ticket - is it still being worked on? Are we likely to see it added to the core at any point? I would really love to have this functionality working! :)

comment:64 @clifgriffin10 months ago

Also voting for this. Would be a very useful feature.

comment:65 @alexvorn210 months ago

we should change priority to major as this is a very requested feature.

comment:66 @DrewAPicture10 months ago

  • Keywords 4.1-early added
  • Milestone changed from Awaiting Review to Future Release

I'd love to get this in in 4.1, or least get a hard decision on yea or nay.

comment:67 follow-up: @spacedmonkey10 months ago

What needs to be done to get this in 4.1? It seems like code is already written. Why can't it be just implemented?

comment:68 in reply to: ↑ 67 @DrewAPicture10 months ago

Replying to spacedmonkey:

What needs to be done to get this in 4.1? It seems like code is already written. Why can't it be just implemented?

It needs a champion (that's me) and a little bit of time to soak. We also have to figure out where to put these archive links. Should they go in the Pages list like the 'Home' link? The ticket's been sitting for a while, is there actually core support? These are unanswered questions.

comment:69 follow-ups: @knutsp10 months ago

Put it in a new listing box "Post Type Archives" and list the post types that have an archive page ('has_archive' => true). Expose this box as a checkbox on Screen Options.

comment:70 in reply to: ↑ 69 @GermanKiwi10 months ago

Replying to knutsp:

Put it in a new listing box "Post Type Archives" and list the post types that have an archive page ('has_archive' => true). Expose this box as a checkbox on Screen Options.

+1 from me for this implementation!

comment:71 in reply to: ↑ 69 @onthisearth10 months ago

Replying to knutsp:

Put it in a new listing box "Post Type Archives" and list the post types that have an archive page ('has_archive' => true). Expose this box as a checkbox on Screen Options.

+1 from me for this implementation!

comment:72 in reply to: ↑ 69 @brent37219 months ago

+1 That's how I'd do it, it's not a page so it doesn't belong in the pages area.

Also agree that severity should be major.

Replying to knutsp:

Put it in a new listing box "Post Type Archives" and list the post types that have an archive page ('has_archive' => true). Expose this box as a checkbox on Screen Options.

comment:73 @brent37219 months ago

Sorry to make things more confusing but I just noticed my issue was caused because my css hook to show the current page was .current_page_item which wasn't working on the archive page. Then I noticed that .current-menu-item does seem to work if you make a 'link' nav item and link it to the name of your custom post type relatively, in my case the post type was work, so '/work/'

Still feels a little hacky to add it in in this way, I think a box for adding post type archives would make more sense to some people.

b r e n t

comment:74 @wonderboymusic8 months ago

  • Owner set to wonderboymusic
  • Status changed from assigned to reviewing

comment:75 follow-up: @celloexpressions8 months ago

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 50 and 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.

comment:76 @wonderboymusic8 months ago

  • Keywords 4.1-early removed
  • Owner wonderboymusic deleted

comment:77 @aaroncampbell8 months ago

Thought I'd weigh in here again.

It's really frustrating to have functionality that exists on my site that the menu system doesn't help me link to. If I have a post type of "beer" and /beers/ exists, I want to see that and be able to link to it.

Having said that, I see that posts is a special case as far as archives. I agree that this "odd man out" issue is a pain, and I'm not totally sure what the best path from here is. I know there are some UI concerns, which pulls this out of my wheelhouse, but I still think it's a gap in our menu system that really needs to be addressed. Maybe the way it's currently being addressed in this ticket isn't the best option, but if that's the case I'd love to hear some other ideas.

comment:78 in reply to: ↑ 75 @helen8 months ago

Replying to celloexpressions:

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).

#16379 - let's not rabbit hole this ticket based on that. I disagree that the UI absolutely has to make all post types equivalent - a user typically does not recognize that they utilize the same thing underneath and does not necessarily expect the same thing from all of them.

Other things aside, though, we do have a base issue of "where do we put this and what does this promise to the user" - does it promise the user that the archive works as they expect it? Is there some bigger picture thing we can think about with other "virtual" pages?

comment:79 @knutsp8 months ago

An archive i WordPress is mostly referring to a virtual page that offers (custom) posts that satisfy some conditions, always a post type, sometimes by date, author or belonging to a taxonomy term. In this regard the "blog" page is the archive for posts.

But an archive is sometimes also used as the opposite of the "blog" page, a virtual page that has some constraints other that post type.

With the introduction of custom post types a virtual page that would loop over all the posts of that type was also called an archive. The only "archive" that is not always called an archive is the blog page, offering all posts (of post type post).

We have the conditional function is_post_type_archive(). I suggest the definition of a post type archive, in this context, is a virtual page that will make this function return true. For now, don't include the built-in post types, as they get special treatment by core anyway.

An archive menu item type should be linked to the slug of the custom post type. Therefore it needs to be a special type, not "custom" (a static link that doesn't respect the actual slug).

I don't see why all non-custom menu item types should be linked only to "objects", in the meaning that each item is tied to a row in a database table (posts, terms users) for the current schema.

I also fail to see why adding another accordion section is so bad.

comment:80 @engelen8 months ago

Even though they don't have their own object in the database, post type and taxonomy archives can be considered as object types in the context of navigation menus, in my opinion. Currently, supposing we have a post type "product" with taxonomy "product_type", the naming is as follows.

For a menu item linking to a certain post:

'_menu_item_type' => 'post_type',
'_menu_item_object' => 'product',
'_menu_item_object_id' => [post ID]

For a menu item linking to a certain product_type term:

'_menu_item_type' => 'taxonomy',
'_menu_item_object' => 'product_type',
'_menu_item_object_id' => [term ID]

I would suggest the following naming for archives.

For post type archives:

'_menu_item_type' => 'post_type_archive',
'_menu_item_object' => 'product'

For taxonomy archives:

'_menu_item_type' => 'taxonomy_archive',
'_menu_item_object' => 'product_type'

Furthermore, I would find it more logical to have two new accordion menus: one for post type archives, and one for taxonomy archives. This maintains the concept that every menu item type/object-combination has its own accordion.

I would be happy to implement a new patch for this when a decision is made.

comment:81 @boonebgorges5 months ago

#30609 was marked as a duplicate.

comment:82 follow-up: @mouloud4 months ago

I would really need this option, but I think like celloexpressions that it relies to deeps concepts in Wordpress. In my opinion, those concepts inherit from the blog history of WordPress, and need to be rethink, as they limit the freedom brang by Custom Post Types.
In the meantime, I support the demand to simply add a filter or action to allow the plugins to edit the menu metabox, so that third parties can propose different options, waiting for the core team to decide which is the best.
Thanks a lot for all the work, folks !

Last edited 4 months ago by mouloud (previous) (diff)

comment:83 in reply to: ↑ 82 @aaroncampbell4 months ago

Replying to mouloud:

In the meantime, it support the demand to simply add a filter or action to allow the plugins to edit the menu metabox, so that third parties can propose different options, waiting for the core team to decide which is the best.
Thanks a lot for all the work, folks !

I'm not totally clear on your wording here, but we did put in the filter you seem to be referencing. The filter went in in [17951] and is now nicely documented and everything. The plugin is old, but you can see how to use it by looking at Custom Post Type Archives in Nav Menus. I suppose I should try to carve out a little time to update that, at least until we put this in core.

comment:84 @mouloud4 months ago

Indeed. And the plugin still works. Thanks a lot.

comment:85 @marsjaninzmarsa3 months ago

That should be in core long time ago...

comment:86 @hlashbrooke11 days ago

I was about to log a ticket for this issue then I came across this. I have, however, already worked on a solution. I haven't tested all the patches added here, but I'll and mine anyway seeing as though I've already finished with it. It works entirely as expected (new 'Post Type Archives' meta box with check boxes for different archives) and everything goes smoothly. It does not include built-in post types because they doesn't seem to make any sense to include.

The only issue that I still can't work around is that the menu item type label still says 'Custom Link' no matter what I do, so some help there would be appreciated if my patch is worth looking at.

@hlashbrooke11 days ago

Details explained in previous comment.

Note: See TracTickets for help on using tickets.