WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 8 months ago

Last modified 8 months ago

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

comment:1 sterlo3 years ago

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.

comment:2 nacin3 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?

comment:3 sterlo3 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'
          )   
        )   
      );  

comment:4 sterlo3 years ago

  • Version set to 3.0.3

comment:5 sterlo3 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.

comment:6 follow-up: sterlo3 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.

comment:8 sterlo3 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.

comment:9 duck_3 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

comment:10 avryl8 months ago

  • Component changed from General to Taxonomy

comment:11 follow-up: wonderboymusic8 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

Has since changed to array( 'show_ui' => true )

comment:12 in reply to: ↑ 11 SergeyBiryukov8 months ago

Replying to wonderboymusic:

Has since changed to array( 'show_ui' => true )

Related: [19089]

Note: See TracTickets for help on using tickets.