Opened 10 years ago
Closed 10 years ago
#30275 closed defect (bug) (fixed)
Exclude breaks wp_list_categories for non-hierarchical categories
Reported by: | thomask | Owned by: | boonebgorges |
---|---|---|---|
Milestone: | 4.1 | Priority: | normal |
Severity: | normal | Version: | 4.0 |
Component: | Taxonomy | Keywords: | |
Focuses: | Cc: |
Description
I'm not sure if this is a bug or just some unhappy intent
wp_list_categories( array (
'taxonomy' => 'post_tag',
'hide_empty' => false,
'exclude' => '123'
) );
return always "no category found" message. When "exclude" is not there, it works normaly, the same for any other option. Hierarchical taxonomies are ok, problem is only with non-hierarchical (even the custom ones).
Problem can be solved by adding hierarchical=false parameter, but it is nowhere written, and not very obvious.
Change History (2)
Note: See
TracTickets for help on using
tickets.
Confirmed.
The back story here is kinda complicated. In [8614],
wp_link_categories()
was modified so that the 'exclude' parameter always got translated into 'exclude_tree'. This makes sense when you use that function for categories (which are hierarchical). But when using it for non-hierarchical taxonomies, it has the side effect of short-circuiting some queries inget_terms()
. In particular,get_terms()
will runget_terms( 'child_of' => $excluded_item )
for each member of$exclude_tree
. But that secondary run ofget_terms()
automatically setschild_of
to 0 for non-hierarchical taxonomies, under what I gather are the auspices of saving an unnecessary query. But in your case, it was causing the secondary call toget_terms()
to return *all* terms in the taxonomy, with the result that *all* terms were being excluded from the query. Thus "no category found".Removing the lines in
get_terms()
that force 'child_of=0' for non-hierarchical taxonomies fixes the problem. What's more: it appears to actually *save* database queries in at least some cases, since a check for term children will return an empty array in these cases, avoiding later lookups. And since [29815], I think we have decent tests for child_of, and better understanding of it, so I feel comfortable taking it out.Thanks for the report.