[wp-trac] [WordPress Trac] #35381: Introduce `WP_Term_Query`

[WordPress Trac]

#35381: Introduce `WP_Term_Query`
-------------------------------------+------------------
 Reporter:  boonebgorges             |       Owner:
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  4.6
Component:  Taxonomy                 |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:
-------------------------------------+------------------
Changes (by boonebgorges):

 * keywords:  has-patch needs-testing dev-feedback => has-patch needs-
               testing


Comment:

 @jtsternberg Thanks for bringing this to my attention.

 Replying to [comment:21 jtsternberg]:
 > > These changes were missed in [37572].
 >
 > Does this, by chance, fix some issues users are experiencing with using
 `get_terms` the old way? Related:
 https://github.com/WebDevStudios/CMB2/issues/653

 No, it's related only to the values passed to the `get_terms` filter.

 To follow up on the linked ticket: The changes in this ticket are designed
 to be 100% backward-compatible. The changes are completely internal to
 `get_terms()`; existing use of `get_terms()` should remain unchanged.

 I don't have complete steps to reproduce, but based on
 https://github.com/WebDevStudios/CMB2/commit/20d4b9529f8285425a72a5c082016aa950c7660c
 I'm guessing that the issue is that arguments are being passed as a
 querystring (`hide_empty=0`) rather than an array. By the looks of things,
 this syntax was supported after [37572] only accidentally, because of the
 use of `wp_parse_args()`. When the use of `wp_parse_args()` early in
 `get_terms()` was removed in [37576], it uncovered this compatibility
 break.

 [attachment:35381.3.diff] should fix the issue by ensuring that
 querystring-style arguments are supported, in both legacy syntax (`(
 $taxonomy, $args )`) and new syntax (`( $args )`). I'm using
 `wp_parse_args()` to do the string parsing, as it makes the syntax a bit
 clearer than referring directly to `wp_parse_str()`.

 @jtsternberg and/or @ipstenu, could you please test
 [attachment:35381.3.diff] to see if it addresses the problem? This should
 supercede
 https://github.com/WebDevStudios/CMB2/commit/20d4b9529f8285425a72a5c082016aa950c7660c

--
Ticket URL: <https://core.trac.wordpress.org/ticket/35381#comment:22>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform