Add query filter argument to register_taxonomy

[tifosi]

Following on from the #21240 ticket which introduced the show_admin_column functionality I would like to suggest an additional argument to easily add the select list query filter for a taxonomy to the post-type list.

Currently a taxonomy query can be added via the 'restrict_manage_posts' action and 'parse_query' filter.

It would be useful to add an additional register_taxonomy argument of 'show_column_filter' to define a standard select option list of the taxonomy terms. Things like default option and hierarchy could be optional settings is an array is passed instead of boolean.

[boonebgorges]

Hi @tifosi - Thanks for the ticket, and sorry for the delay in response. I'm not sure I understand your use case. Which admin panel are you trying to modify with this new parameter - Dashboard > Posts? Exactly what changes would the parameter make? The more specifics you can give, the more likely we'll be able to see whether there's a worthwhile addition here.

[tifosi]

Thanks for the reply. Wondered if this would get looked at in the taxonomy bug scrub.

WP 3.5 added the 'show_admin_column' arg to allow automatic creation of taxonomy columns on associated post types.

It is possible to add a select dropdown filter for the taxonomy in such a situation using judicious use of the 'restrict_manage_posts' action and 'parse_query' filters. This displays between the apply & filter buttons to the right of the 'show all dates' select.

Would be a functional addition to have a 'show_filter' argument to register_taxonomy() args to display this filter automatically for associated post-types. This would only trigger if 'show_admin_column' is also set to be true/1.

Essentially this filters the post-type list and only displays the posts associated to the selected taxonomy term. Nice feature when working with multiple terms per taxonomy. In theory & practice if you have a post-type and 3 taxonomies you can drill-down via this method with a select per taxonomy.

Example code below I've used in my own framework. Note this was used in a class, so $this in code examples:

<?php
add_action( 'restrict_manage_posts', array( $this, '_post_type_filter' ) ); //in __construct
public function _post_type_filter() {

    //required presets
    global $typenow, $wp_query;

    //only if current post type
    if ( $typenow !== $this->post_type_name ) { return; }

    //get current taxonomy
    $current_taxonomy = get_taxonomy( $this->taxonomy_name );

    //only if query_var
    if ( empty( $current_taxonomy->query_var ) ) { return; }

    //terms
    $tax_terms = get_terms( $this->taxonomy_name );
    $tax_term_count = (int)sizeof( $tax_terms );

    //need terms...
    if ( $tax_term_count === 0 ) { return; }

    //dropdown select
    wp_dropdown_categories(
         array(
              'show_option_all' =>  __( "Show All {$current_taxonomy->label}" ),
              'taxonomy'                =>  $this->taxonomy_name,
              'name'                    =>  $current_taxonomy->name,
              'orderby'                 =>  'name',
              'selected'                =>  ( isset( $wp_query->query[$this->taxonomy_name] ) ) ? $wp_query->query[$this->taxonomy_name] : '',
              'hierarchical'    =>  true,
              'depth'           =>  3,
              'show_count'      =>  true,
              'hide_empty'      =>  true,
         )
    );
}

<?php
add_filter( 'parse_query', array( $this, '_post_type_filter_query') ); //in construct
public function _post_type_filter_query( $query ) {

    //required page
    global $pagenow;

    //test page
    if ( $pagenow !== 'edit.php' ) { return; }

    //set filter
    $vars = &$query->query_vars;
    if ( $pagenow == 'edit.php' && isset( $vars[ $this->taxonomy_name ] ) && is_numeric( $vars[$this->taxonomy_name] ) ) {
         $term = get_term_by( 'id', $vars[ $this->taxonomy_name ], $this->taxonomy_name );
         if ( $term ) { $vars[ $this->taxonomy_name ] = $term->slug; }
    }
}

[boonebgorges]

@tifosi Thanks for the clarification. I understand the request now.

I think it's a decent idea. It's hard to think of a parameter name that's not confusing - show_admin_filter is a bit clearer than show_filter, but I'd like to see if anyone has a better idea than this.

[tifosi]

show_admin_filter works for me. Links with show_admin_column more semantically. Having the filter display only when show_admin_column is true/1 is the important factor.

Thanks

[DrewAPicture]

If it's the post filter drop-downs we're talking about, e.g.

Does show_admin_column work for multiple taxonomy > post type associations? If so, I'd guess this would work similarly.

Either way, I think something like show_post_filter or even show_admin_post_filter is a little closer. If you wanted to go abstract, you could use show_content_filter instead.

[tifosi]

The idea is to have it as an argument to register_taxonomy() alongside show_admin_column. As such i'd prefer show_admin_filter with the documentation caveat that it requires show_admin_column to be true/1 to work.

That would be a per-taxonomy argument. Multiple taxonomies per post type would be handled on a 1:1 basis, i.e. as arguments in respective register_taxononmy() calls.

Ideally multiple active taxonomy filters could provide a 'quick' drill-down functionality within the post-type admin interface, particularly useful for custom post-types.

Thanks

[DrewAPicture]

Replying to tifosi:

The idea is to have it as an argument to register_taxonomy() alongside show_admin_column. As such i'd prefer show_admin_filter with the documentation caveat that it requires show_admin_column to be true/1 to work.

Why should showing the column be a prerequisite to showing a completely different part of the UI? As it is, show_admin_filter is pretty vague. Filtering what exactly? :-)

That would be a per-taxonomy argument. Multiple taxonomies per post type would be handled on a 1:1 basis, i.e. as arguments in respective register_taxononmy() calls.

I was talking about cases where a single taxonomy is associated with multiple post types.

--

Either way, a first-run patch would be good so we aren't talking in the theoretical.

[boonebgorges]

Let's bikeshed the name of the parameter after we have a patch :)

[tifosi]

@DrewAPicture Do you fully understand the concept of the ticket request?

show_admin_filter is meant to be a select/dropdown filter for an associated taxonomy's terms. As such if show_admin_column isn't set as an argument for that taxonomy's register_taxonomy call then it's counterintuitive to display the filter if the taxonomy column isn't also displayed. That doesn't preclude though using it if you essentially want the select filter to replace the in-column drill down method so unlinking it may be an option.

show_admin_filter isn't at all vague - it's semantically and functionally related to show_admin_column, naming it show_post_filter would imo cause confusion semantically linking it just to posts. It's "filtering" the taxonomy it's an argument to, for the post-type it's associated with.

As the argument is tied to the taxonomy creation then if a taxonomy is associated with a post-type - either through the register_taxonomy() call or later with register_taxonomy_for_object_type then it would display for whichever post-type admin list ui the taxonomy is associated with, whether single or multiple.

bikeshed away... I'll leave it with you.

[DrewAPicture]

Replying to tifosi:

@DrewAPicture Do you fully understand the concept of the ticket request?

Yeah, I think I have a pretty good understanding of how core works and what you're asking :-)

show_admin_filter is meant to be a select/dropdown filter for an associated taxonomy's terms. As such if show_admin_column isn't set as an argument for that taxonomy's register_taxonomy call then it's counterintuitive to display the filter if the taxonomy column isn't also displayed. That doesn't preclude though using it if you essentially want the select filter to replace the in-column drill down method so unlinking it may be an option.

The point is that they should realistically be mutually exclusive. Developers do all sorts of different things with these screens and deliberately tying one option to another makes it less flexible in the long run.

show_admin_filter isn't at all vague - it's semantically and functionally related to show_admin_column, naming it show_post_filter would imo cause confusion semantically linking it just to posts. It's "filtering" the taxonomy it's an argument to, for the post-type it's associated with.

As the argument is tied to the taxonomy creation then if a taxonomy is associated with a post-type - either through the register_taxonomy() call or later with register_taxonomy_for_object_type then it would display for whichever post-type admin list ui the taxonomy is associated with, whether single or multiple.

Taxonomies can be associated with more than just post objects of any post type, they can also be associated with comments, users, links, etc. So I'll concede show_post_filter is too narrow. In that vein, show_admin_filter is too vague. And yes, we can bikeshed all day but lacking a patch the entire discussion is moot. :-)

@tifosi Would you like to submit a patch?