Add Post Type Archives support in Nav Menus

[matzipan]

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/

[matzipan]

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

[nacin]

There might be a duplicate of this ticket somewhere.

[travisnorthcutt]

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.

[raulillana]

Woking on this actually, dealing with the walker.

Someone more on this?

[dd32]

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

[raulillana]

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

[raulillana]

only post type archives implemented in fase1

[aaroncampbell]

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?

[aaroncampbell]

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.

[markjaquith]

I have no objection to that filter.

[aaroncampbell]

Moving this to 3.2 to get the filter added.

[markjaquith]

In [17951]:

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

[aaroncampbell]

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.

[travisnorthcutt]

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

[aaroncampbell]

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

[aaroncampbell]

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)

[travisnorthcutt]

That's fantastic. Thanks for doing this!

[aaroncampbell]

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

[raulillana]

Kudos! Works like a charm. :)

[WraithKenny]

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.

[WraithKenny]

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

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

[aaroncampbell]

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.

[travisnorthcutt]

Any chance of this getting into core for 3.4?

[maorb]

+1 for getting this into core.

[sscovil]

I agree. +1 for getting this into core.

[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?

[aaroncampbell]

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

[DrewAPicture]

post_parent

[DrewAPicture]

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

[sabreuse]

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

[DrewAPicture]

Refresh

[Frank Klein]

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.

[DrewAPicture]

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]

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.

[ericlewis]

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.

[paulwilde]

Refreshed ericlewis' patch to work with trunk.

[helen]

#27396 was marked as a duplicate.

[GermanKiwi]

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! :)

[clifgriffin]

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

[alexvorn2]

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

[DrewAPicture]

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

[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?

[DrewAPicture]

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.

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

[GermanKiwi]

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!

[onthisearth]

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!

[brent3721]

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

[brent3721]

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

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

[aaroncampbell]

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.

[helen]

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?

[knutsp]

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.

[engelen]

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.

[boonebgorges]

#30609 was marked as a duplicate.

[mouloud]

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 !

[aaroncampbell]

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.

[mouloud]

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

[marsjaninzmarsa]

That should be in core long time ago...

[hlashbrooke]

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]

Details explained in previous comment.

[helen]

#32910 was marked as a duplicate.

[knutsp]

Any hope for this in 4.4? Who is reviewing?

[chriscct7]

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.

[aaroncampbell]

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:

And would look like this in the menus:

The alternative would be to add the checkbox to the top of the existing post type meta boxes:

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

[johnbillion]

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

[aaroncampbell]

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.

[knutsp]

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.

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

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.

[seanchayes]

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

[chriscct7]

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

[aaroncampbell]

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?

[seanchayes]

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' )
                )
                );

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

[DrewAPicture]

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

[aaroncampbell]

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?

[DrewAPicture]

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

[aaroncampbell]

16075.7.diff​ is refreshed

[helen]

Fine with it going into the all items tab.

[aaroncampbell]

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

[DrewAPicture]

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

[wonderboymusic]

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.

[wonderboymusic]

only thing that remains is the Customizer piece

[celloexpressions]

Customizer first-pass

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

[westonruter]

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.

[aaroncampbell]

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

[westonruter]

In 35500:

Customize: Add support for post_type_archive nav menu items.

Props celloexpressions, westonruter.
Fixes #16075.

[swissspidy]

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' ); 
}

[westonruter]

In 35501:

Customize: Simplify condition for returning nav_menus_invalid_post_type error.

Props swissspidy.
See #16075.

[nacin]

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

[DrewAPicture]

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"?

[DrewAPicture]

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.

[jorbin]

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.

[SergeyBiryukov]

In 39666:

Posts, Post Types: Add a @since entry for archives post type label introduced in [35382].

See #16075.