[wp-trac] [WordPress Trac] #18106: get_terms of posts in a specific post_type

[WordPress Trac]

#18106: get_terms of posts in a specific post_type
-------------------------------+----------------------
 Reporter:  braydonf           |       Owner:
     Type:  feature request    |      Status:  closed
 Priority:  normal             |   Milestone:
Component:  Taxonomy           |     Version:
 Severity:  normal             |  Resolution:  wontfix
 Keywords:  close needs-patch  |     Focuses:
-------------------------------+----------------------
Changes (by boonebgorges):

 * status:  new => closed
 * resolution:   => wontfix
 * milestone:  Awaiting Review =>


Comment:

 `get_terms()` never makes reference to `wp_term_relationships`, so
 probably isn't the place for this kind of argument. It belongs somewhere
 like `wp_get_post_terms()`.

 The simplest way to implement this: in `wp_get_post_terms()`, if
 `$post_id` is empty and `$args['post_type']` is not, then fetch the IDs of
 the posts in the post type(s) and pass them to `wp_get_object_terms()`.
 This is probably going to perform very slowly on large sites, and if your
 site is large enough you may even experience the joy of a seg fault. I
 don't think this is something we'd want to put into core.

 It's hard to think of a more robust solution that won't look pretty
 hackish. `wp_get_object_terms()` is designed to be agnostic about the
 object type (post, user, etc). But filtering by post_type is very specific
 to posts. So, you can imagine passing a 'primary_id_column' and
 'primary_table' column to `wp_get_object_terms()` to build the necessary
 JOIN clause, but it's hard to imagine the generic logic that would be
 necessary to build a WHERE clause like `p.post_type IN ('post','page')`.
 It'd be out of keeping with the rest of WP to have functions passing
 chunks of SQL between each other. At the same time, it doesn't make a lot
 of architectural sense to put logic directly into `wp_get_object_terms()`
 that is specific to posts (or, worse, post_type). And even if we did, we'd
 be looking at a query that'd be pretty slow for large numbers of posts.

 On the basis of this, I'm closing as wontfix. Official recommendation for
 now is to query for post IDs on your own and pass to
 `wp_get_object_terms()`. If someone shows up here with a dynamite patch
 that proves me wrong, I'll eat my foot and dub you the champion of
 WordPress.

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