[wp-trac] [WordPress Trac] #38280: Make term count for a specific object type available

[WordPress Trac]

#38280: Make term count for a specific object type available
--------------------------------------+------------------------------
 Reporter:  desrosj                   |       Owner:  (none)
     Type:  enhancement               |      Status:  new
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  Taxonomy                  |     Version:  4.7
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+------------------------------

Comment (by boonebgorges):

 [attachment:38280.10.diff] makes the change pointed out by
 @ivankristianto, which I was in the process of patching when he posted his
 comment :)

 Fixing this error uncovers some bug that I haven't grasped yet. The logic
 of `wp_get_term_count_for_object_type()` is basically: see if we have a
 cached count, but if not, call `wp_update_term_count_now()`, and then re-
 call `wp_get_term_count_for_object_type()`, the idea being that calling
 `wp_update_term_count_now()` should always populate the cached count. But
 this doesn't appear to be happening in all cases, so that this recursive
 call ends up with an infinite regress. This appears to happen when the
 taxonomy is associated with more than one object type, and when term_id
 and term_taxonomy_id are out of sync, which suggests that there's still
 some inconsistency there. Try running [attachment:38280.10.diff] with the
 entire `--group taxonomy` and you'll see what I mean.

 I made a couple other changes as well:
 - In `_update_post_term_count()`, you were double-escaping the
 `$object_types` (`esc_sql()` + `$wpdb->prepare()`). Your rearrangement
 means that the `esc_sql()` call is no longer needed, so I've removed it.
 - Rearranged the logic at the end of `wp_get_term_count_for_object_type()`
 to make it clearer what's being returned in the last case.
 - In the complex tests, use a custom taxonomy rather than category.
 Category has all sorts of special cases ('Uncategorized', etc) and, at
 first, I thought it might be the cause of the bug described above, though
 perhaps I'm wrong about that.
 - Don't return `false` from `wp_get_term_couont_for_object_type()` in case
 of a bad object type. Seems more informative and more internally
 consistent to return a `WP_Error`.

 Perhaps @ivankristianto or @desrosj will be able to look at the errors and
 find what's causing the infinite regress. To me, it's sort of a code smell
 - ideally, the function wouldn't need to call itself again to get the
 cached value, though I realize the underlying count functions don't return
 friendly values.

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