[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