[wp-trac] [WordPress Trac] #38280: Make term count for a specific object type available
WordPress Trac
noreply at wordpress.org
Thu Jul 5 15:55:40 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 desrosj):
Replying to [comment:22 boonebgorges]:
>
> How does this general approach feel to others?
I like this approach a lot. It feels a lot more natural.
[attachment:"38280.16.diff"] adds tests for the new meta retrieval
function.
Some questions.
- 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?
- 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.
- If the second attempt to get the object count after the "no count found"
hook fails, should a `WP_Error` be returned?
Also, I think `wp_get_term_count_for_object_type_from_meta()` could also
return `false` when an object does not belong to a taxonomy. Object types
can be removed from a taxonomy and not have their counts updated for quite
some time. Returning `false` here would trigger a recount and flush the
removed object type from the meta cache.
> How about `wp_get_term_object_count()`?
Sounds good to me. I made name changes and tweaked some docblocks to more
accurately indicate what is counted in [attachment:"38280.16.diff"].
>
> I also have questions about the "if" conditions where I put the comment
`are these right?`. I know that these are meant to be shortcuts, but I
worry that they have the potential to produce corrupted data. For example,
the `1 >= count( $taxonomy_object->object_type )` call assumes that
plugins have properly registered their taxonomies with object types - but
do we enforce this elsewhere? What if the `$taxonomy_object->object_type`
is not the same as `$object_type`? It seems better to return no data in
these cases than to return something potentially incorrect. Can anyone
help to think through the possibilities here?
When a taxonomy is registered, no object type validation is performed. So,
you could register a `foo` object type for a taxonomy even if `foo`
objects are not registered. Maybe `1 >= count(
$taxonomy_object->object_type )` could be changed to count the number of
object types that currently exist instead. This would add a need to
compare the number of object types stored in `_wp_counted_object_types`
with the number of active in order to trigger recounting if an object type
is removed, but could prevent inaccurate counts when an object type is
removed.
I also created [https://travis-ci.org/desrosj/wordpress-
develop/builds/400503713 a branch on my WordPress Develop fork] to show
the tests passing. This branch reflects [attachment:"38280.16.diff"].
--
Ticket URL: <https://core.trac.wordpress.org/ticket/38280#comment:24>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list