[wp-trac] [WordPress Trac] #34243: Make `get_taxonomy()` work like `get_post_type()`

WordPress Trac noreply at wordpress.org
Sat Oct 10 14:01:02 UTC 2015


#34243: Make `get_taxonomy()` work like `get_post_type()`
-------------------------+-----------------------------
 Reporter:  flixos90     |      Owner:
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  Taxonomy     |    Version:  trunk
 Severity:  normal       |   Keywords:
  Focuses:               |
-------------------------+-----------------------------
 After term splitting and having finished up #14162, I think it would be
 useful to add / adjust standardized functions to terms that have been
 there for posts as well.

 We need simple functions for making it easier to work with term IDs
 independently, just like we can work with post IDs.

 In particular, I'm proposing to add a function like `get_taxonomy( $term
 )` that works like `get_post_type( $post )` and returns the taxonomy name.

 The issue now is that there already exists a function of that name, but it
 basically works more like `get_post_type_object( $post_type )`. What I'm
 thinking is we could modify the `get_taxonomy()` function to support both
 kinds of functionalities. In addition to the above, we could introduce a
 new function `get_taxonomy_object( $taxonomy )`. The two functions could
 be something like this:

 {{{
 function get_taxonomy( $term ) {
     // new get_taxonomy() behavior
     if ( is_numeric( $term ) || is_object( $term ) && isset(
 $term->term_id ) ) {
         if ( $term = get_term( $term ) )
             return $term->taxonomy;

         return false;
     }

     // old behavior for back compat
     return get_taxonomy_object( $term );
 }

 function get_taxonomy_object( $taxonomy ) {
     global $wp_taxonomies;

     if ( ! taxonomy_exists( $taxonomy ) )
         return false;

     return $wp_taxonomies[$taxonomy];
 }
 }}}

 At a later stage we could possibly deprecate the old way of using
 `get_taxonomy()` so that developers would be recommended to use the new
 function instead of the old one.

 Having one function serve two purposes might be a little confusing, but
 when we think long-term, this would be an acceptable caveat in my opinion.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/34243>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list