#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)
Change History (140)
#2
in reply to:
↑ description
@
14 years ago
#3
@
14 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
@
14 years ago
- Cc johnbillion@… added
- Keywords nav menus post type archive registered entry removed
#6
@
14 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.
#9
@
14 years ago
- Keywords needs-patch removed
What's the go with the foreach loop in wp_nav_menu_post_type_archives_meta_box()
?
#11
@
14 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
#14
@
14 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
@
14 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.
#18
@
13 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.
#20
@
13 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:
↓ 22
@
13 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
@
13 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
@
13 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)
#25
follow-up:
↓ 29
@
13 years ago
The plugin is in the wp.org repository now: Custom Post Type Archives in Nav Menus
#27
@
13 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
@
13 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:
↓ 30
@
13 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
@
13 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.
#41
follow-up:
↓ 42
@
12 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
@
12 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
#50
@
12 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
@
12 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
@
12 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.
#53
@
12 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.
#63
@
10 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! :)
#66
@
10 years 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:
↓ 68
@
10 years 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
@
10 years 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:
↓ 70
↓ 71
↓ 72
@
10 years 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
@
10 years 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
@
10 years 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
@
10 years 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
@
10 years 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
#75
follow-up:
↓ 78
@
10 years 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.
#77
@
10 years 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
@
10 years 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
@
10 years 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
@
10 years 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.
#82
follow-up:
↓ 83
@
10 years 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 !
#83
in reply to:
↑ 82
@
10 years 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.
#86
@
9 years 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.
#89
@
9 years 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
@
9 years 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:
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).
This ticket was mentioned in Slack in #core by aaroncampbell. View the logs.
9 years ago
#92
@
9 years 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
#94
follow-up:
↓ 95
@
9 years 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
@
9 years 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:
↓ 99
@
9 years 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:
↓ 98
@
9 years 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
@
9 years 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
@
9 years 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
@
9 years 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:
↓ 102
@
9 years 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
@
9 years 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
@
9 years 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
@
9 years 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.
#105
@
9 years ago
16075.7.diff is refreshed
#106
@
9 years ago
- Keywords ui-feedback needs-testing needs-refresh removed
Fine with it going into the all items tab.
#108
@
9 years 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.
#112
follow-up:
↓ 113
@
9 years 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
@
9 years 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
@
9 years 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.
#116
@
9 years 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' ); }
#118
follow-up:
↓ 119
@
9 years 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
@
9 years 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"?
It seems the same problem applies to taxonomies (these being added without hardcoded entry)