Make WordPress Core

Opened 14 years ago

Closed 13 years ago

#14704 closed defect (bug) (duplicate)

_get_term_hierarchy() should check for populated array

Reported by: zaremedia's profile zaremedia Owned by:
Milestone: Priority: normal
Severity: minor Version:
Component: General Keywords:
Focuses: Cc:

Description

http://core.trac.wordpress.org/browser/trunk/wp-includes/taxonomy.php#L2311

By default, the 'category_children' option is populated with a serialized empty PHP array. So upon first call, it correctly yields an *empty* array. This code succeeds in the if() block and returns the empty array to the calling function.

My suggestion is to change this to something like: if (!empty($children))

Attachments (1)

taxonomy.php.patch (516 bytes) - added by aaires 14 years ago.

Download all attachments as: .zip

Change History (16)

#1 @nunomorgadinho
14 years ago

True. I've just hit this issue as well.

#2 @aaires
14 years ago

I experienced the same problem, not being able to see the children terms if the option "{$taxonomy}_children" isn't updated. If that happens there is no possibility to retrieve the children through the terms.

In attach (taxonomy.php.patch) you can find the patch that simple adds the check to see if the $children array is not empty, as suggested here.

#3 @scribu
14 years ago

  • Milestone changed from Awaiting Review to 3.1

Huh, very sneaky bug indeed.

#4 @scribu
14 years ago

On the other hand, having it check is_empty() will trigger an extra query on each page load if you don't have any sub-categories.

#5 @scribu
14 years ago

  • Milestone 3.1 deleted
  • Resolution set to worksforme
  • Status changed from new to closed

By default, the 'category_children' option is populated with a serialized empty PHP array.

I don't think this is true. The option is updated every time clean_term_cache() is called.

So, creating or deleting a category should fix it.

#6 @somatic
14 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

This problem is still affecting me, when programmatically spawning terms and specifying parents with wp_insert_term()

$kid_term = wp_insert_term( $kid, $taxonomy, array( 'parent'=> $parent_id, 'slug'=> sanitize_title($kid) ) );

I can see the terms in the DB, and in wp_term_taxonomy table their parent *is* set, but the wp_option table items for {taxonomy}_children is stuck on an empty array.

wp_insert_term() includes a call to clean_term_cache(), but if it's doing anything, it's still not updating the {taxonomy}_children field.

If I manually (through the wp_admin interface) set a term to have a parent, the option gets updated and displays correctly.

I've even included a call to clean_term_cache() after all my wp_insert_term() calls are done - still nothing.

HOWEVER - if I go and delete one my terms in the wp_admin interface, the option gets updated - and of course clean_term_cache() is called in wp_delete_term() - so sometimes it's doing it's job and sometimes it's not....

#7 @somatic
14 years ago

just tested the patch by aaires, basically replicating the _get_term_hierarchy code as a function within my plugin, and implementing the conditional:

&& !empty($children)

Works perfect. Scribu, can you test your assertion? "creating or deleting a category should fix it"

#8 @scribu
14 years ago

I've even included a call to clean_term_cache() after all my wp_insert_term() calls are done - still nothing.

Could you post the code for that?

#9 @garyc40
14 years ago

Related to #14485

#10 @nacin
14 years ago

  • Milestone set to Future Release

#11 @maorb
14 years ago

  • Cc maorb added

#12 follow-up: @foofy
14 years ago

This is only a problem if you make multiple term changes in the same PHP request/script lifetime. clean_term_cache() tracks each taxonomy it cleans in a static variable and won't clean it a second time. If several term changes are made in the same request, the {$taxonomy}_children option is left with the hierarchy as it was after the first change.

_get_term_hierarchy() has the only other reference to that option and is responsible for repopulating it if it's empty, so it seems safe to delete the option manually.

I don't know why it doesn't clear a taxonomy more than once (I guess it's performance-related) so I didn't want to mess with that, but I think the $clean_taxonomy parameter was meant to be an override that got neutered at some point.

#13 in reply to: ↑ 12 @garyc40
14 years ago

Replying to foofy:

I don't know why it doesn't clear a taxonomy more than once (I guess it's performance-related) so I didn't want to mess with that, but I think the $clean_taxonomy parameter was meant to be an override that got neutered at some point.

See #14485

#14 @dd32
13 years ago

Duplicate of #14485 (and #16051, #14704, #17356)

#15 @dd32
13 years ago

  • Milestone Future Release deleted
  • Resolution set to duplicate
  • Status changed from reopened to closed

Duplicate of #14485 (and #16051, #14704, #17356)

Note: See TracTickets for help on using tickets.