#15837 closed defect (bug) (invalid)
Custom Taxonomy: Admin Menu Not Selecting Current Item
Reported by: | sterlo | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.0.3 |
Component: | Taxonomy | Keywords: | |
Focuses: | Cc: |
Description
Story: Developing a plugin that adds a Custom Post Type and then a Taxonomy.
Problem: Adding the Taxonomy and displaying the Menu Item on the Admin section, when selecting the menu item - there seems to be a difference in functionality depending on what tag the Taxonomy hooks onto.
For example code:
register_taxonomy( 'mytaxonomy', 'myposttype', array( 'labels' => array( 'name' => 'Manage XXX', 'add_new_item' => 'Add New XXX', 'new_item_name' => 'New XXX Name', 'add_new' => 'Add New XXX', 'singular_name' => 'XXX' ), 'public' => false, 'publicly_queryable' => true, 'show_ui' => true, 'hierarchical' => true, 'rewrite' => array( 'slug' => 'XXX', 'with_front' => false ), 'query_var' => 'XXX' ) );
The above code adds the Menu Item for the Taxonomy to the new Custom Post Type menu I created.
When I select the new Taxonomy...it "open" or "behaves" as though it expects to see it under the "post" tag.
It does not select the Taxonomy Menu Item as "current".
Expected result: Select Taxonomy Menu Item -> Menu Item obtains CSS class of "current".
Actual result: Select Taxonomy Menu Item -> Menu Item doesn't obtain a CSS class and IF the Posts menu was "collapsed" it expands.
Now - conversely if I add the Taxonomy Menu Item to the tag "post" - it DOES add the CSS class.
This seems to be inconsistent functionality and I believe that it's not there's something surrounding it that has to be malfunctioning.
Change History (12)
#2
@
13 years ago
Can we have the code for both the post type registration and the taxonomy registration?
Also, what version of WordPress are you using?
Can you try the latest beta to see if it is fixed there?
#3
@
13 years ago
Version of WordPress is Version 3.0.3 - I can attempt to try the latest beta.
Here's the post type registration:
register_post_type( 'staff_listing', array( 'labels' => array( 'name' => 'Staff Listings', 'add_new_item' => 'Add a Staff Member', 'new_item' => 'Staff Member', 'add_new' => 'Add a Staff Member', 'singular_name' => 'Staff Member' ), 'public' => false, 'publicly_queryable' => true, 'show_ui' => true, 'hierarchical' => false, 'rewrite' => array( 'slug' => 'staff', 'with_front' => false ), 'query_var' => 'staff', 'supports' => array( 'title', 'editor', 'thumbnail', 'comments', 'revisions' ) ) );
#5
@
13 years ago
Tested on latest beta:
http://wordpress.org/news/2010/04/wordpress-3-0-beta-1/
Here's the bare-bones Plugin I created:
https://gist.github.com/749013
Figured out the issue...
So if you set the following in the register_post_type call:
'public' => false
Then any additional menu items added to it will not receive their proper styling.
Not sure if this is a bug or if that's intentional.
#6
follow-up:
↓ 7
@
13 years ago
public (boolean) (optional) Meta argument used to define default values for publicly_queriable, show_ui, show_in_nav_menus and exclude_from_search. Default: false * 'false' - do not display a user-interface for this post type (show_ui=false), post_type queries can not be performed from the front end (publicly_queryable=false), exclude posts with this post type from search results (exclude_from_search=true), hide post_type for selection in navigation menus (show_in_nav_menus=false) * 'true' - show_ui=true, publicly_queryable=true, exclude_from_search=false, show_in_nav_menus=true
So ... If I set public => false...and then set show_ui=true, publicly_queryable=true, exclude_from_search=false, show_in_nav_menus=true ... the problem still persists.
Seems like a bug or possibly that we need another parameter for this.
#7
in reply to:
↑ 6
@
13 years ago
Replying to sterlo:
Source: http://codex.wordpress.org/Function_Reference/register_post_type#Parameters
#8
@
13 years ago
When I looked at the commit log for the latest dev build I saw this:
------------------------------------------------------------------------ r17169 | westi | 2010-12-29 08:25:22 -0800 (Wed, 29 Dec 2010) | 1 line Ensure the Parent menu is hilighted correctly when Custom Post Types are shown under an existing top level menu. Fixes #16015 props duck_.
I will test this to see if the problem is resolved.
#9
@
13 years ago
This problem is caused by:
if ( empty( $post_type ) || !in_array( $post_type, get_post_types( array( 'public' => true ) ) ) ) $post_type = 'post';
In WP_Terms_List_Table for 3.1 and edit-tags.php for 3.0.x
By only checking against public it resets $post_type to post in the backend so that the $parent_file gets set to edit.php
instead of edit.php?post_type=$post_type
Quick fix to confirm this was to just go with get_post_types()
, no parameters, but someone with a bit more time needs to look into the history of why it's currently public. A quick look got references to [13215] and #9674
If anyone has any light to shed on this "perceived" issue - please let me know.
I will do some code debugging over the weekend and see what the objects involved are interacting with and what data they are working with in order to trouble shoot this and provide more useful information.