WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#26903 closed defect (bug) (fixed)

get_terms returns no terms with 'parent' => 0 with non-empty child terms

Reported by: mrwweb Owned by: wonderboymusic
Milestone: 3.9 Priority: normal
Severity: normal Version: 3.8
Component: Taxonomy Keywords: has-patch commit
Focuses: Cc:

Description

I'm filing this to reopen #17365 which I think was closed incorrectly due to not understanding the OP.

I don't want to repeat the entire ticket which has a lot of good details, so read it first.


I'll illustrate the bug with an example...

Consider the following Food taxonomy term hierarchy and counts:

  • Cheese (0)
    • Cheddar (2)
    • Brie (7)
  • Crackers (0)
    • Butter (1)
    • Multigrain (3)
  • Fruit (0)
    • Cranberries (0)

This structure implies 9 cheese posts, 4 cracker posts, and no fruit posts.

According to the get_terms documentation, get_terms( 'my_food_tax', array( 'parent' => 0 ) ) should return Cheese and Crackers because hierarchical defaults to true and those terms (Cheese and Crackers) have non-empty children (Cheddar, Brie, Butter, and Multigrain). However, this currently returns NO terms.

As the OP points out, this seems to be because setting 'parent' => 0 resets some of the stated defaults.

However, this isn't just a problem with accurate documentation. As best I can tell, there is no way to override this behavior so the expected return value (Cheese and Crackers) is impossible to achieve without some kind of hack. I tried adding 'pad_counts' => true and 'hierarchical' => true in hopes that would help but it doesn't.

Attachments (1)

26903.diff (3.8 KB) - added by wonderboymusic 4 years ago.

Download all attachments as: .zip

Change History (12)

@wonderboymusic
4 years ago

#1 @wonderboymusic
4 years ago

  • Keywords has-patch commit added
  • Milestone changed from Awaiting Review to 3.9

This was another brutal one. _get_term_children() was defying logic in some cases. All unit tests pass. I added a mega unit test that does exactly what this ticket describes. Gonna let this sit til tomorrow in case someone wants to chime in.

#2 @mrwweb
4 years ago

Sweet. At least in my project, this seems to resolve the issue.

#3 @wonderboymusic
4 years ago

  • Resolution set to fixed
  • Status changed from new to closed

Fixed in [27108], which for some reason didn't post here or trigger an email.

#4 @wonderboymusic
4 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Last night, it came to me that I didn't write tests for parent => 0 and more than one-level deep of empties before hitting a term with count > 0

#5 @wonderboymusic
4 years ago

  • Owner set to wonderboymusic
  • Resolution set to fixed
  • Status changed from reopened to closed

In 27125:

When a term_id matches in _get_term_children(), recurse through its children until there is no more depth in the hierarchy. Since get_terms() return terms with a count of 0 when their children are not empty, we must return all children so that get_terms() can check their count.

In [27108], #26903 was fixed, but only because we were using the example in the ticket, leaving out infinite depth for hierarchical taxonomies.

Adds unit tests, including Tests_Term_getTerms::test_get_terms_seven_levels_deep().

Fixes #26903. Again.

#6 @SergeyBiryukov
4 years ago

#17365 was marked as a duplicate.

#7 @SergeyBiryukov
4 years ago

In 27197:

Add @ticket references. see #26903.

#8 follow-up: @markjaquith
4 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

The unit test is randomly failing for me.

Tests_Term_getTerms::test_get_terms_seven_levels_deep
Failed asserting that an array is not empty.

tests/phpunit/tests/term/getTerms.php:323

#9 in reply to: ↑ 8 ; follow-up: @SergeyBiryukov
4 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

Replying to markjaquith:

The unit test is randomly failing for me.

See comment:ticket:14485:88, it's handled there.

#10 in reply to: ↑ 9 @markjaquith
4 years ago

Replying to SergeyBiryukov:

Replying to markjaquith:

The unit test is randomly failing for me.

See comment:ticket:14485:88, it's handled there.

That's a really awkward workaround to counteract something that shouldn't be happening. [27115] should just be reverted.

#11 @nacin
4 years ago

In 27300:

Revert [27115] and let cache backends handle the stripping of spaces in cache keys as necessary.

microtime() returns greater precision than microtime(true).

see #27000, #23448, #26903, #14485.

Note: See TracTickets for help on using tickets.