[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