WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 8 months ago

#32942 new defect (bug)

Taxomony term list counts do not respect post_type parameter

Reported by: stueynet Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.1
Component: Taxonomy Keywords: ux-feedback needs-patch needs-screenshots
Focuses: administration Cc:

Description

Assuming you have a shared taxonomy, when viewing the post_type specific manage terms page, the post_type is not respected in the term counts. So if you have 6 posts for post_type 1 and 5 posts in post_type 2 assigned to the same taxonomy term (category->news for example), the post count for the news term will be 11 even if you are viewing the edit-tags page with the post_type set to a specific type.

So whether you go to

wp-admin/edit-tags.php?taxonomy=category

or go to:

wp-admin/edit-tags.php?taxonomy=category&post_type=example

The term count for each term is the same. When calculating term counts, it should take into account the post_type parameter and return counts for just that post_type.

The link in the edit-tags.php list behaves as expected. It links to wp-admin/edit.php?category=news&post_type=example which shows just the list of example posts in the news category. Its misleading to the user because in the taxonomy term list under a specific post type it says there are X posts assigned to that term, but when they click the link there displays a different number of posts. This is because the term list is displaying the count of all posts, regardless of type, that have that term assigned.

Attachments (2)

Screenshot-2018-5-14 Kommuner.png (12.8 KB) - added by knutsp 13 months ago.
The shared Location taxonomy (search result)
Screenshot-2018-5-14 Stilling som assistent ledig.png (25.4 KB) - added by knutsp 13 months ago.
Actual posts found, in one of the post types, after clicking the count number (2) from previous screenshot

Download all attachments as: .zip

Change History (20)

#1 @jorbin
4 years ago

  • Keywords ux-feedback added
  • Milestone changed from Awaiting Review to Future Release
  • Version changed from trunk to 3.1

This dates at least as far back as list tables introduction in 3.1.

I'm not sure if the bug is the fact that we don't display the correct count here, that we don't make it clear what the count is a count of, or that there is no easy way to pivot between the post types of a specific taxonomy. It's likely some combination of this all.

#2 @stueynet
4 years ago

Looking over the many related and closed tickets over the years, it seems clear that the expected behavior on that page is to display counts associated with the post type in context. if someone wants to see a general count for all post types associated with a shared taxonomy, that would likely need to live somewhere else.

Current workflow is to view a term list from within a custom post type, see a count next to the term, click the count, and end up with a list of posts that differs from the count.

I'd be happy to give this fix a try.

#3 follow-up: @stueynet
4 years ago

  • Keywords needs-patch added

Just thought I would follow up a bit on this one. After examining the code the issue is that the $tag object which is used to display the count in the Count column of the terms table, uses get_terms. get_terms does not care about post_type. So this could never have worked.

In wp-admin/includes/class-wp-terms-list-table.php on line 200 the display_rows_or_placeholder() method calls get_terms on line 224.

So the solution is to add the ability to set a post_type parameter to the get_terms() function. Then updated the call to get_terms above to include that parameter.

I will have a look at how to do that next.

#4 in reply to: ↑ 3 @boonebgorges
4 years ago

Replying to stueynet:

Just thought I would follow up a bit on this one. After examining the code the issue is that the $tag object which is used to display the count in the Count column of the terms table, uses get_terms. get_terms does not care about post_type. So this could never have worked.

Yes, this sounds correct.

So the solution is to add the ability to set a post_type parameter to the get_terms() function. Then updated the call to get_terms above to include that parameter.

A 'post_type' argument for get_terms() probably is not going to happen. Read #18106 for some back story, but basically (a) the taxonomy component is object-type agnostic - by design, it doesn't know anything about posts, (b) the table joins that would be required would perform horrendously. For the case of this list table, we'll probably have to do something like this:

$posts_in_post_type = get_posts( array(
    'fields' => 'ids',
    'post_type' => $this->screen->post_type,
    'posts_per_page' => -1,
) );

$args['include'] = = wp_get_object_terms( $posts_in_post_type, $taxonomy, array( 'ids' ) );
$terms = get_terms( $taxonomy, $args );

This is not the most elegant thing in the world, but I think it's probably OK for these term tables.

This ticket was mentioned in Slack in #core by mark-k. View the logs.


2 years ago

#7 follow-up: @mark-k
2 years ago

If the get_terms API can not properly return the count in the requested context, than what is the use of it returning a count at all?

Or stated differently, if the result of the API is not reliable then the WP_Terms_List_Table class should not rely on the count returned by it and run additional query to get the correct number, or not show it at all.

#8 in reply to: ↑ 7 @SergeyBiryukov
2 years ago

Replying to mark-k:

If the get_terms API can not properly return the count in the requested context, than what is the use of it returning a count at all?

#38280 and #39372 should resolve this.

#9 @SergeyBiryukov
2 years ago

#41255 was marked as a duplicate.

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


14 months ago

#11 follow-up: @melchoyce
14 months ago

The design team looked at this ticket today in our weekly design triage and are confused. Can someone explain how and where a taxonomy would be shared?

#12 in reply to: ↑ 11 @knutsp
14 months ago

Replying to melchoyce:

The design team looked at this ticket today in our weekly design triage and are confused. Can someone explain how and where a taxonomy would be shared?

I'm a bit confused about this question.

I have two custom post types (advertisement_sale and advertisement_buy). They share the same taxonomy location. Convenient, because then visitors may see both sales and buying advertisements by same location.

Bu when I view my locations in the admin, below a specific post type, the number of specific posts for each term is most important. Secondly, to view all posts of any type that have it.

Last edited 14 months ago by knutsp (previous) (diff)

This ticket was mentioned in Slack in #design by melchoyce. View the logs.


14 months ago

This ticket was mentioned in Slack in #design by melchoyce. View the logs.


13 months ago

#15 @melchoyce
13 months ago

  • Keywords needs-screenshots added

@knutsp Thanks. Would you mind adding some screenshots?

@knutsp
13 months ago

The shared Location taxonomy (search result)

@knutsp
13 months ago

Actual posts found, in one of the post types, after clicking the count number (2) from previous screenshot

#16 @knutsp
13 months ago

So I may think there is two posts of this post type by looking at the count number, but there is actually only one. If I go to the same taxonomy, below the other post type, I also see 2, but again only one in that post type.

My only point is that this count is unclear for shared taxonomies. Ideally, both could have been shown. Subsidiary, only show the count for the actual post type in view.

Currently, the count is confusing and/or inaccurate, as long as the context is a specific post type.

This ticket was mentioned in Slack in #core by davecpage. View the logs.


11 months ago

#18 @SergeyBiryukov
8 months ago

#45051 was marked as a duplicate.

Note: See TracTickets for help on using tickets.