[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):

 Replying to [comment:19 desrosj]:
 > [attachment:38280.13.diff] removes `bool` from the
 `wp_get_etrm_count_for_object_type()` inline documentation and adds the
 taxonomy to the first `WP_Error` that is returned when a taxonomy does not
 exist. Also fixes a 3 minor alignment and spacing issues in the unit tests
 to adhere to the coding standards.
 >
 > @boonebgorges Do you think adding a return value to
 `_update_post_term_count()` is realistic? It is a pretty old function
 (2.3), but adding a return value (or at least a `false` return when it
 fails) would solve the infinite loop issue.

 Thank you sir. I don't think it's feasible to change the return value for
 the `update` functions, for a few reasons. One is backward compatibility.
 Another is that taxonomy terms can be attached to things that aren't
 posts, which means that the `count` fallback needs to be more resiliant.
 [attachment:38280.14.diff] has a test that demonstrates this - the test,
 along with [attachment:38280.13.diff], will trigger the infinite regress.

 [attachment:38280.14.diff] has one proof-of-concept way to avoid the
 regress. Basically: break the call to termmeta into its own reusable
 function. The function returns `false` if no meta is found, indicating a
 count should take place. If it returns false, then we trigger
 `wp_update_term_count_now()`, and then fetch from meta again. If it's
 *still* false, we just return `0` from the function. Upside: No more
 regress, even for non-post-type objects.

 Downside: `wp_get_term_count_for_object_type( $term_id, $non_post_type )`
 will *always* trigger a recount, except when a plugin updates the term-
 object counts itself. This seems dangerous. So, an alternative technique
 might be to simply bail out of `wp_get_term_count_for_object_type()` if
 the `object_type` is (a) not found in `_wp_counted_object_types` (this
 covers cases where the plugin properly handles term counts), and (b) is
 not a post type. This `0` return value for non-post-types could be
 filtered, in case a plugin wants to do something fancy.

 I'm thinking that this latter technique might be the simplest and safest,
 but I'd welcome feedback before writing yet another patch :-D

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