Allow a single taxonomy to be passed to get_terms() as an array.

[mfields]

The inline docs for get_terms() state that the $taxonomies parameter may contain either a string or an array.

@param string|array $taxonomies Taxonomy name or list of Taxonomy names

I've just ran into a situation where this is not the case. The following code works fine and should list all children of the term with and id of 174:

$terms = get_terms( 'category', array( 'child_of' => 174 ) );
print '<pre>' . print_r( $terms, true ) . '</pre>';

However, if the taxonomies parameter is given in an array, all categories will be returned:

$terms = get_terms( array( 'category' ), array( 'child_of' => 174 ) );
print '<pre>' . print_r( $terms, true ) . '</pre>';

I believe that both examples should produce the same results.

This behavior can be observed in WordPress 3.1.4 as well as 3.2.

This behavior can be observed in WordPress 3.1.4 as well as 3.2.

Going to assume it affects the whole 3.1 branch then.

Version is for the earliest version affected - helps us track things like regressions.

Set $single_taxonomy to false if count is greater than 1

Is it ever necessary to test earlier than the latest stable branch? For instance, is there any reason to test in 3.0?

Replying to mfields:

Is it ever necessary to test earlier than the latest stable branch? For instance, is there any reason to test in 3.0?

It can be helpful yes. We're always going to be curious if it ever worked. It's very common for us to trace code back to the point of change or introduction, which may result in some very small changeset numbers. If it did, then it was a regression somewhere along the line.

And if it ever worked, how recently did it stop working? A 3.2 regression (something that worked in 3.1) at this stage in the cycle is a blocker. If you presented me a 3.0 to 3.1 regression a few weeks ago, that would have been something we would have prioritized. As something is broken for longer, the lower priority it gets. I've been known to fire up WordPress 2.7 from time to time, and have test installs for every branch from around there on up.

Thanks for the detailed explanation. I'll do some testing an see if I can get to the bottom of this.

Going back to 2.3 when this function was introduced, it appears that get_terms() was never able to accept a single taxonomy in an array with the 'child_of' argument set. The logic which controls the value of the $single_taxonomy boolean has remained the same ever since as well as most things before the args are parsed. Would a bug like this be a good candidate for early 3.3? If not considered a bug, I feel that the documentation should definitely be updated to reflect this case.

Just count() arrays

This just bit me and wasted 30 minutes of my time. Seems like a sensible fix that would be highly useful to get in!

Re-patched, only sets $single_taxonomy in one place, instead of 3

In 22417:

Treat a single taxonomy passed as an array the same as when passed as a string in get_terms(). props wonderboymusic, fixes #17955.