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

WordPress Trac noreply at wordpress.org
Fri Jul 20 20:55:32 UTC 2018


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

 > I agree with @desrosj here, $taxonomy_object->object_type could be
 different and we didn't enforced that. I prefer we remove that condition
 and go straight get the count from the meta / recount it. It's more safe
 rather than return false data.

 I've made this change in [attachment:"38280.18.diff"]. Note that this also
 means that `_wp_counted_object_types` and
 `_wp_object_count_{$object_type}` is now set for *every* term. This is not
 ideal, especially when most taxonomies are, in fact, used only with a
 single object type. So I'm on the fence about it. The alternative strategy
 would be to stick with the `1 === count( ... )` technique, and urge the
 importance of proper object-type registration and custom count callbacks
 for custom taxonomies, somewhere in the documentation. What do others
 think?

 > Should the priority of core's wp_no_object_term_count_found hook be
 higher than the default of 10 to ensure it runs before custom hooks?

 I don't see a powerful reason for doing this. It's just as likely - maybe
 more? - that a developer will want to hook in *before* the core callback,
 so as to call `remove_action()`.

 > Should wp_get_term_count_for_object_type() have a dynamic hook that
 allows a filter to only be added for a specific taxonomy?
 "wp_term_count_for_object_type_$taxonomy", for example.

 Dynamic hooks make the most sense when the generic hook is called so
 frequently that the numerous calls to `call_user_func()` cause performance
 problems. I don't think that's going to be the case for
 `'wp_term_object_count'`. So my preference would be to err on the side of
 fewer, and more general, hooks, and devs can check `$term->taxonomy` in
 their callbacks. Happy to hear counterarguments, though.

 > If the second attempt to get the object count after the "no count found"
 hook fails, should a WP_Error be returned?

 I guess that would be like:

 {{{
 $count = wp_get_term_object_count_from_meta( $term_id, $object_id );
 if ( false === $count ) {
     return new WP_Error( ... );
 }

 $count = (int) $count;
 }}}

 Is that right? What information would the error provide to a developer? I
 guess that the object type is not a post type, and the plugin in question
 didn't properly register a count callback?

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


More information about the wp-trac mailing list