WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 7 months ago

Last modified 4 months ago

#16075 closed task (blessed) (fixed)

Add Post Type Archives support in Nav Menus

Reported by: matzipan Owned by: aaroncampbell
Milestone: 4.4 Priority: normal
Severity: normal Version: 3.1
Component: Menus Keywords: has-patch
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 (17)

16075_fase1.patch (11.3 KB) - added by raulillana 5 years ago.
only post type archives implemented in fase1
16075.diff (4.0 KB) - added by aaroncampbell 5 years ago.
16075-just-filter.diff (795 bytes) - added by aaroncampbell 5 years ago.
16075.2.diff (3.7 KB) - added by aaroncampbell 5 years ago.
16075.2-refresh.diff (3.5 KB) - added by DrewAPicture 3 years ago.
16075.3.diff (3.5 KB) - added by DrewAPicture 3 years ago.
post_parent
16075.4.diff (3.5 KB) - added by DrewAPicture 3 years ago.
Refresh
16075.5.diff (5.9 KB) - added by ericlewis 3 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 2 years ago.
16075-hlashbrooke.diff (5.1 KB) - added by hlashbrooke 14 months ago.
Details explained in previous comment.
16075.6.diff (6.3 KB) - added by aaroncampbell 10 months ago.
menus-post-type-archives-01.jpg (67.5 KB) - added by seanchayes 10 months ago.
customizer-post-type-archives-01.jpg (50.7 KB) - added by seanchayes 10 months ago.
16075.7.diff (6.7 KB) - added by aaroncampbell 9 months ago.
customizer-nav-menus.png (44.2 KB) - added by aaroncampbell 9 months ago.
16075.customize.diff (1.1 KB) - added by celloexpressions 8 months ago.
Customizer first-pass
16075.customize.2.diff (2.3 KB) - added by westonruter 8 months ago.

Download all attachments as: .zip

Change History (139)

#1 @matzipan
5 years ago

  • Cc matzipan added

#2 in reply to: ↑ description @matzipan
5 years ago

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

#3 @nacin
5 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.

#4 @johnbillion
5 years ago

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

#5 @raulillana
5 years ago

  • Cc raulillana added

#6 @travisnorthcutt
5 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.

#7 @raulillana
5 years ago

Woking on this actually, dealing with the walker.

Someone more on this?

#8 @raulillana
5 years ago

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

#9 @dd32
5 years ago

  • Keywords needs-patch removed

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

#10 @raulillana
5 years ago

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

@raulillana
5 years ago

only post type archives implemented in fase1

#11 @raulillana
5 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

#12 @johnbillion
5 years ago

  • Cc johnbillion@… removed

#13 @johnbillion
5 years ago

  • Cc johnbillion@… added

@aaroncampbell
5 years ago

#14 @aaroncampbell
5 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?

#15 @aaroncampbell
5 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.

#16 @mau
5 years ago

  • Cc ngomau@… added

#17 @markjaquith
5 years ago

I have no objection to that filter.

#18 @aaroncampbell
5 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.

#19 @markjaquith
5 years ago

In [17951]:

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

#20 @aaroncampbell
5 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.

#21 follow-up: @travisnorthcutt
5 years ago

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

#22 in reply to: ↑ 21 @aaroncampbell
5 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).

#23 @aaroncampbell
5 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 5 years ago by aaroncampbell (next)

#24 @travisnorthcutt
5 years ago

That's fantastic. Thanks for doing this!

#25 follow-up: @aaroncampbell
5 years ago

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

#26 @raulillana
5 years ago

Kudos! Works like a charm. :)

#27 @WraithKenny
5 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.

#28 @WraithKenny
5 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.

#29 in reply to: ↑ 25 ; follow-up: @raulillana
5 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. ;)

#30 in reply to: ↑ 29 @aaroncampbell
5 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.

#31 @travisnorthcutt
4 years ago

  • Keywords 3.3-early removed

Any chance of this getting into core for 3.4?

#32 @toscho
4 years ago

  • Cc info@… added

#33 @maorb
4 years ago

  • Cc maor@… added

+1 for getting this into core.

#34 @wpsmith
4 years ago

  • Cc travis@… added

#35 @sscovil
4 years ago

I agree. +1 for getting this into core.

#36 @aaroncampbell
4 years ago

  • Cc aaroncampbell added

#37 @jkudish
3 years ago

  • Cc jkudish added

#38 @husobj
3 years ago

  • Cc ben@… added

#39 @Marco_Teethgrinder
3 years ago

  • Cc marco@… added

#40 @rfair404
3 years ago

  • Cc rfair404 added

#41 follow-up: @rfair404
3 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?

#42 in reply to: ↑ 41 @aaroncampbell
3 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

#43 @DrewAPicture
3 years ago

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

#44 @DrewAPicture
3 years ago

  • Keywords needs-refresh removed

#45 @DrewAPicture
3 years ago

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

@DrewAPicture
3 years ago

post_parent

#46 @DrewAPicture
3 years ago

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

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

#47 @DrewAPicture
3 years ago

  • Keywords needs-testing added

#48 @sabreuse
3 years ago

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

@DrewAPicture
3 years ago

Refresh

#49 @DrewAPicture
3 years ago

  • Keywords needs-testing removed

#50 @Frank Klein
3 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.

#51 @DrewAPicture
3 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

@ericlewis
3 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.

#52 @DrewAPicture
3 years ago

  • Milestone changed from Future Release to Awaiting Review

#53 @ericlewis
3 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.

#54 @emzo
3 years ago

  • Cc wordpress@… added

#55 @mfields
3 years ago

  • Cc michael@… added

#56 @mtekk
3 years ago

  • Cc mtekkmonkey@… added

#57 @alexvorn2
3 years ago

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

#58 @aaroncampbell
3 years ago

  • Severity changed from major to normal

#59 @c3mdigital
3 years ago

  • Keywords needs-refresh added

#60 @Frank Klein
2 years ago

  • Cc contact@… added

#61 @paulwilde
2 years ago

  • Keywords needs-refresh removed

Refreshed ericlewis' patch to work with trunk.

#62 @helen
2 years ago

#27396 was marked as a duplicate.

#63 @GermanKiwi
2 years 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! :)

#64 @clifgriffin
23 months ago

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

#65 @alexvorn2
23 months ago

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

#66 @DrewAPicture
23 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.

#67 follow-up: @spacedmonkey
23 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?

#68 in reply to: ↑ 67 @DrewAPicture
23 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.

#69 follow-ups: @knutsp
23 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.

#70 in reply to: ↑ 69 @GermanKiwi
23 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!

#71 in reply to: ↑ 69 @onthisearth
23 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!

#72 in reply to: ↑ 69 @brent3721
22 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.

#73 @brent3721
22 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

#74 @wonderboymusic
21 months ago

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

#75 follow-up: @celloexpressions
21 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.

#76 @wonderboymusic
21 months ago

  • Keywords 4.1-early removed
  • Owner wonderboymusic deleted

#77 @aaroncampbell
21 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.

#78 in reply to: ↑ 75 @helen
21 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?

#79 @knutsp
21 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.

#80 @engelen
21 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.

#81 @boonebgorges
18 months ago

#30609 was marked as a duplicate.

#82 follow-up: @mouloud
18 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 18 months ago by mouloud (previous) (diff)

#83 in reply to: ↑ 82 @aaroncampbell
18 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.

#84 @mouloud
18 months ago

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

#85 @marsjaninzmarsa
16 months ago

That should be in core long time ago...

#86 @hlashbrooke
14 months 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.

@hlashbrooke
14 months ago

Details explained in previous comment.

#87 @helen
12 months ago

#32910 was marked as a duplicate.

#88 @knutsp
10 months ago

Any hope for this in 4.4? Who is reviewing?

#89 @chriscct7
10 months ago

There's plenty of time for this to land in 4.4, but no one (at least according to trac) has owned or is reviewing this atm.

#90 @aaroncampbell
10 months ago

  • Milestone changed from Future Release to 4.4
  • Owner set to aaroncampbell
  • Status changed from reviewing to accepted

I'll go ahead and take ownership on this one for now. The first thing we need to do is decide what kind of promises we think we're making to the users here and if we can fulfill those. Like @Helen said:

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?

How common is the case where a plugin adds a post type with an archive, but the theme doesn't display the archive correctly?

After we figure that out, we need to make some UI decisions. The main thing here is:

Do the checkboxes for archives go in the existing post type boxes (an "Archive" checkbox at the top of each that has an archive?) or do they go in a metabox of their own?

This would mean a new screen option:
https://cldup.com/uhWZrdWf22D/t7h437.png

And would look like this in the menus:
https://cldup.com/uhWZrdWf22D/jOk0Bv.png

The alternative would be to add the checkbox to the top of the existing post type meta boxes:
https://cldup.com/uhWZrdWf22D/GpaZ8j.png

Once we do all that, we'll also need to extend this solution to the nav menus in the customizer (something neither the most current patch or the plugin here do).

This ticket was mentioned in Slack in #core by aaroncampbell. View the logs.


10 months ago

#92 @johnbillion
10 months ago

  • Owner changed from aaroncampbell to johnbillion
  • Status changed from accepted to assigned

My Extended CPTs library does this. It adds an item to the All tab for the post type and uses the all_items post type label for its label.

Related: #32367

#93 @johnbillion
10 months ago

  • Owner changed from johnbillion to aaroncampbell

#94 follow-up: @aaroncampbell
10 months ago

  • Keywords needs-testing added

16075.6.diff is based on a short conversation in Slack. Instead of using the all_items label for a post type, it adds a new archives label. The archives label will default to the all_items label if not specified and if no labels are given it will use either "Post Archives" or "Page Archives" depending on if the post type is hierarchical.

It also adds a checkbox, using the new archives label, to the top of the View All tab for any post type that has an archive.

It adds a new menu item type of post_type_archive, which stores the post_type as the object, so that the url can be pulled using get_post_type_archive_link( $menu_item->object ) instead of being stored like custom menu items. This way, if a site changes permalink structure, the link stays correct just like post links do.

Lastly, it adds the current-menu-item class to the menu item if is_post_type_archive( array( $menu_item->object ) ).

I still don't love the UI. It's not obvious to find it in the all items tab, I'm just not sure where else to put it.

#95 in reply to: ↑ 94 @knutsp
10 months ago

Replying to aaroncampbell:

Excellent work. Important that it's a dynamic link based on current permalink settings, not fixed as a custom link.

I still don't love the UI. It's not obvious to find it in the all items tab, I'm just not sure where else to put it.

The most important thing is that it is there. Having "All {post_type}s" in the all items tab isn't actually non-intuitive, I would say. Not ideal, ok.

#96 follow-up: @seanchayes
10 months ago

I pulled down this patch as I too would like this functionality (to avoid using custom links). Tested out well in both the Menus screen as well as the Customizer.

One odd behavior I found relates to the Screen Options checkboxes on the Menus screen. There was an instance, that I can't seem to repeatedly and consistently replicate >:-| I found that adding a check to a box such as "Custom Links" or "Format" enabled not only the selected checkbox/option but all of them upon menu save. As a result all the side drop down accordions would show. A minor inconvenience but not desired in that example. I have a feeling it only happens once and then after a period of time. I did try to debug where that could be being triggered from but couldn't figure it out.

I think having the "All Items" label for each relevant post type should exist within it's post type accordion box (as you have it). Having that link in "View All" is fairly intuitive but does take an extra click to find it but it is there and functional.

Having said that, in the Customizer all CPT navigation options are available regardless of the checked items' status in screen options so it could be argued to show all the CPT accordions in the Menus screen.

As it relates to the customizer screen it does show an option for the CPT but the label is not correct (lower case in this example) and the related post type archive link doesn't show up. (See following images)

Great work regardless.

#97 follow-up: @seanchayes
10 months ago

Darn... I uploaded one image twice - they are the same image and I can't work out how to remove the 02 variant.

#98 in reply to: ↑ 97 @chriscct7
10 months ago

Replying to seanchayes:

Darn... I uploaded one image twice - they are the same image and I can't work out how to remove the 02 variant.

I've removed it

#99 in reply to: ↑ 96 @aaroncampbell
10 months ago

Replying to seanchayes:

I pulled down this patch as I too would like this functionality (to avoid using custom links). Tested out well in both the Menus screen as well as the Customizer.
...
As it relates to the customizer screen it does show an option for the CPT but the label is not correct (lower case in this example) and the related post type archive link doesn't show up. (See following images)

Adding this to the Customizer is still on the todo list. 16075.6.diff doesn't address the customizer at all...maybe I'll get to it this weekend, if not then probably next week.

As for the discrepancy in accordion labels between Menus and Customizer Menus, that might need a new ticket. Can you paste in your code that is being used to create this post type (including all it's labels) so I can take a look?

#100 @seanchayes
10 months ago

Sure - thanks for clarifying about the customizer

The register CPT code below is what I used and now you focus on it I see that it took the CPT "singular_name" entry for the Customizer and in my labels array it had a lower case el. That explains that.

register_post_type( 'listing' ,
                array(
                        'labels' => array(
                                'name'                  => __( 'Listings', 'domain' ),
                                'singular_name'         => __( 'listing', 'domain' ),
                                'all_items'         => __( 'Listings', 'domain' ),
                                'add_new'               => __( 'Add New', 'domain' ),
                                'add_new_item'          => __( 'Add New Listing', 'domain' ),
                                'edit'                  => __( 'Edit', 'domain' ),
                                'edit_item'             => __( 'Edit Listing', 'domain' ),
                                'new_item'              => __( 'New Listing', 'domain' ),
                                'view'                  => __( 'View Listing', 'domain' ),
                                'view_item'             => __( 'View Listing', 'domain' ),
                                'search_items'          => __( 'Search Listings', 'domain' ),
                                'not_found'             => __( 'No Listings found', 'domain' ),
                                'not_found_in_trash'    => __( 'No Listings found in Trash', 'domain' ),
                                'parent'                => __( 'Parent Listing', 'domain' ),
                                'capability_type'       => 'post',
                        ),
                        'public'                => true,
                        'show_ui'               => true,
                        'publicly_queryable'    => true,
                        'exclude_from_search'   => false,
                        'description'           => __( 'The description', 'domain' ),
                        'menu_position'         => 5,
                        'supports'              => array( 'title', 'thumbnail', 'author' ),
                        'rewrite'               => array( 'with_front' => false ),
                        'has_archive'           => 'listings',
                        'query_var'             => 'listing',
                        'taxonomies'            => array( 'property_type', 'property_location' )
                )
                );

#101 follow-up: @wonderboymusic
10 months ago

I like this. I want to love it, but the listing in View All seems weird. It should either have an indicator after it, something like - Archive or there should be an accordion section that is all the available archives of different types.

#102 in reply to: ↑ 101 @DrewAPicture
9 months ago

Replying to wonderboymusic:

I like this. I want to love it, but the listing in View All seems weird. It should either have an indicator after it, something like - Archive or there should be an accordion section that is all the available archives of different types.

For what it's worth, there was discussion about placement back when we were refreshing menus in 3.6 about doing a new accordion section for "common links" or similar, and maybe simultaneously moving the "home" link out of the pages accordion there at the same time (since it's a "custom link" in with the pages).

#103 @aaroncampbell
9 months ago

I'm happy to put these wherever we decide they should go. I'd just really like to get them in :)

I personally don't love the idea of a catch all accordion for links that don't fix somewhere else (which is really what I think that would turn into).

As for the way it's labeled in the "View All" tab, that's something you can control when making the CPT:

<?php
$labels = array(
    /* Other labels*/
    'archives' => 'My Custom Post Type Archives',
);

$args = array(
    /* Other args */
    'labels'      => $labels,
    'has_archive' => true,
);

register_post_type( 'mycpt', $args );

So if they wanted a '- Archives' they could. I'm not sure WE can add that though, because wouldn't that be impossible to properly translate?

#104 @DrewAPicture
9 months ago

  • Keywords needs-refresh added

@aaroncampbell Patch needs a refresh. Let's just put it in the respective post type 'all' view like we do for the "Home" link in pages.

#106 @helen
9 months ago

  • Keywords ui-feedback needs-testing needs-refresh removed

Fine with it going into the all items tab.

#107 @aaroncampbell
9 months ago

We need to decide where to put them in the customizer too:

#108 @DrewAPicture
8 months ago

@aaroncampbell For the Customizer, let's put it at the top of the post type item list (mimicking how the Home link is added at the top of the Pages list in the add items flyout.

#109 @wonderboymusic
8 months ago

  • Type changed from enhancement to task (blessed)

#110 @wonderboymusic
8 months ago

In 35382:

Nav Menus: show custom post type Archive item at the top of the View All tab for the post type on the legacy Nav Menu screen.

Props aaroncampbell, DrewAPicture, seanchayes, hlashbrooke, paulwilde, ericlewis, raulillana
See #16075.

#111 @wonderboymusic
8 months ago

only thing that remains is the Customizer piece

@celloexpressions
8 months ago

Customizer first-pass

#112 follow-up: @celloexpressions
8 months ago

16075.customize.diff gets us most of the way there for the customizer. It adds the UI but saving is broken - something in the JS (I think, or possibly the setting class in php) that isn't handling the new type properly. If no one else can figure it out, westonruter probably could since he wrote most of those pieces, but I'm guessing it's not too difficult.

#113 in reply to: ↑ 112 @westonruter
8 months ago

Replying to celloexpressions:

16075.customize.diff gets us most of the way there for the customizer. It adds the UI but saving is broken - something in the JS (I think, or possibly the setting class in php) that isn't handling the new type properly. If no one else can figure it out, westonruter probably could since he wrote most of those pieces, but I'm guessing it's not too difficult.

I think 16075.customize.2.diff fixes the breakages you saw. The object type needs to be supplied, and the logic for how _invalid is determined needs to account for the post_type_archive type.

#114 @aaroncampbell
8 months ago

  • Keywords commit added

I tested 16075.customize.2.diff and it seems to be working well. I think this is ready to commit and close.

#115 @westonruter
8 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 35500:

Customize: Add support for post_type_archive nav menu items.

Props celloexpressions, westonruter.
Fixes #16075.

#116 @swissspidy
8 months ago

That else statement in [35500] could be simplified as follows:

<?php
$post_type = get_post_type_object( $object ); 

if ( ! $post_type ) { 
  return new WP_Error( 'nav_menus_invalid_post_type' ); 
}

#117 @westonruter
8 months ago

In 35501:

Customize: Simplify condition for returning nav_menus_invalid_post_type error.

Props swissspidy.
See #16075.

#118 follow-up: @nacin
7 months ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

I think this string should just be 'Archive', not 'Post Type Archive'.

#119 in reply to: ↑ 118 @DrewAPicture
7 months ago

  • Keywords commit removed

Replying to nacin:

I think this string should just be 'Archive', not 'Post Type Archive'.

Do you think switching to the generic "Archive" string might generate future confusion if we ever add term archive or other archive support though? Or would all of the above then be considered "Archive"?

This ticket was mentioned in Slack in #core by wonderboymusic. View the logs.


7 months ago

#121 @DrewAPicture
7 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

Let's stick with the more specific string for clarity in the short term and if need later demands, the specificity will be helpful to differentiate between the different types of archives.

#122 @jorbin
4 months ago

In 36859:

Ensure Description is respected in post type archive menu items.

Tested scenarios include: using the default (which is the post type description), Setting a custom description for that individual menu item, and setting a custom description that is blank. Introduced in r35382.

Props Toro_Unit, mayukojpn, extendwings, jorbin.
Fixes #35324. See #16075.

Note: See TracTickets for help on using tickets.