[wp-trac] [WordPress Trac] #34175: Add correlating get_fields_terms filter for get_terms

WordPress Trac noreply at wordpress.org
Tue Oct 6 19:20:17 UTC 2015


#34175: Add correlating get_fields_terms filter for get_terms
--------------------------+-----------------------------
 Reporter:  wpsmith       |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Taxonomy      |    Version:  trunk
 Severity:  normal        |   Keywords:
  Focuses:  performance   |
--------------------------+-----------------------------
 Currently, there is a filter (`get_terms_fields`) to filter the fields to
 select in the terms query. I believe that the use of this filter could be
 easily expanded to involve additional return types. So I would like to
 introduce a filter (`get_terms_fields_terms`) for the return `$_terms`
 that would only be called if `$_fields` is not one of the already pre-
 defined options (i.e., `all`, `id=>parent`, `ids`, `names`, `id=>name`,
 `id=>slug`).

 While someone could possibly use `get_terms` to do this manipulation, the
 specified/default query will still execute and be cached, and there is no
 way to really do what one wants to do without having to re-do the entire
 function, which in my opinion is not preferable. Also modifying the
 `get_terms_fields` will modify the cached results of all queries with the
 same taxonomies and arguments.

 It is noted in the filter (`get_terms_fields`) documentation that "Use of
 this filter can result in unpredictable behavior, and is not recommended."
 Based on my limited testing, I found that changing the return fields
 (e.g., `array( 't.slug', 't.name', 'tt.count', 'tt.taxonomy' )`) via
 `get_terms_fields` causes the following issues:
 * If you do not change the default fields argument or use `all`, PHP
 throws an error with updating the cache (`update_term_cache` called
 because `'all' == $_fields` and there is no check for the term ID there or
 within `update_term_cache` since `update_term_cache` rightly assumes that
 $terms is an array of term objects).
   * Notice: Undefined property: `stdClass::$term_id` ...
 * If you use one of the following pre-defined examples, `id=>parent`,
 `ids`, `id=>name`, `id=>slug`), each of these will throw an error if
 `get_terms_fields` removes the term_id (`'t.term_id'`).
   * Notice: Undefined property: `stdClass::$term_id` ...
 * If using `all` and wanting `pad_counts`, another error is thrown by
 `_pad_term_counts` which assumes the first parameter is an array of term
 objects (not IDs, see #34174).
 * If you are trying to get a term list of a specific parent (e.g.,
 $child_of), more errors persist as `_get_term_children` (which calls
 `get_term`) also assumes that `$terms` is an array of term objects (like
 `update_term_cache`) or an integer (`term_id`). This is perpetuated even
 further by utilization of expected object members (e.g., `$term->parent`);
 * If you are trying to hide empty terms (`hide_empty`) this causes another
 error as it also assumes that $terms is an array of term objects.
 * If you are passing in `update_term_meta_cache` then `$term_ids =
 wp_list_pluck( $terms, 'term_id' );` causes another error as does
 `update_termmeta_cache`.
 * Potential errors within themes & plugins

 A possible solution is to patch wp_pluck_list (#34172) & add checks using
 `wp_pluck_list` (see patch).

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


More information about the wp-trac mailing list