Opened 9 years ago
Last modified 15 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: | reporter-feedback has-patch needs-testing |
Focuses: | ui, 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 (9)
Change History (49)
#1
@
9 years ago
- Keywords ux-feedback added
- Milestone changed from Awaiting Review to Future Release
- Version changed from trunk to 3.1
#2
@
9 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:
↓ 4
@
9 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
@
9 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.
8 years ago
#7
follow-up:
↓ 8
@
8 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.
This ticket was mentioned in Slack in #design by karmatosed. View the logs.
7 years ago
#11
follow-up:
↓ 12
@
7 years 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
@
7 years 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.
This ticket was mentioned in Slack in #design by melchoyce. View the logs.
7 years ago
This ticket was mentioned in Slack in #design by melchoyce. View the logs.
6 years ago
#15
@
6 years ago
- Keywords needs-screenshots added
@knutsp Thanks. Would you mind adding some screenshots?
@
6 years ago
Actual posts found, in one of the post types, after clicking the count number (2) from previous screenshot
#16
@
6 years 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.
6 years ago
This ticket was mentioned in Slack in #design by karmatosed. View the logs.
5 years ago
#20
@
5 years ago
- Keywords ux-feedback removed
This seems to need accessibility specific feedback, so let's remove the ux-feedback label and get that focus on this.
#21
follow-up:
↓ 22
@
5 years ago
The expected UX behaviour is to show the actual counts associated with the post type in context. After clicking the count number, it should end up with a list of posts that has same count.
#22
in reply to:
↑ 21
@
5 years ago
Replying to ibdz:
The expected UX behaviour is to show the actual counts associated with the post type in context. After clicking the count number, it should end up with a list of posts that has same count.
A list of posts that has that has the same count of published posts, since that is where it goes today on taxonomies only used by one post type.
If we want something else, like the count being drawn from all posts, or the link is to a filtered list, ´post_status=publish´, then that is out of scope for this ticket.
@
17 months ago
I have create one solution but I need some design suggestion, I have added title attribute so, on hover it will display text for two different count values, but then also I need some suggestion for make more better.
@
17 months ago
Count value displaying in two parts, 1 for current post type's post count and 2nd was total count. could anyone suggest better design or UI?
#24
@
17 months ago
- Keywords reporter-feedback 2nd-opinion needs-design-feedback needs-design added; needs-screenshots removed
This ticket was mentioned in Slack in #slackhelp by chiragrathod103. View the logs.
17 months ago
#26
@
17 months ago
Hey,
here is my opinion for manage count UI. we can try to separate the top 2 labels displaying, 1 for the current post count and 2nd label could be all count.
you can see mentioned screenshot.
Thank you
#27
follow-up:
↓ 30
@
17 months ago
@chiragrathod103 Can we change the text of the Current count to post-type name count and count to all count?
For example, if the post type name is an event so it will display as event count and All count
#29
in reply to:
↑ 28
@
17 months ago
Replying to sumitsingh:
Hey @chiragrathod103 @mikinc860 ,
Looking good last solution 😄
Thanks @sumitsingh for your feedback.
#30
in reply to:
↑ 27
@
17 months ago
Thank you @dhruvishah2203 and @mikinc860 for your suggestion and improvement.
This ticket was mentioned in Slack in #core by chiragrathod103. View the logs.
17 months ago
#33
follow-ups:
↓ 35
↓ 36
@
16 months ago
What happens if we have 4-5…10 post types using the taxonomy? We'll have many columns…
Maybe we can have only one column and add a count per post type below the overall count?
#34
@
16 months ago
@audrasjb I have checked the patch but @chiragrathod103 have displayed only 2 column 1 for the current post type counts and 2 columns for all post type counts. so as of my understanding patch is working fine, it's not creating multiple columns for the post type.
#35
in reply to:
↑ 33
@
16 months ago
Replying to audrasjb:
What happens if we have 4-5…10 post types using the taxonomy? We'll have many columns…
Nope, each post will display only 2 columns, 1st for the current post type and 2nd for all post types counts ( including the current post count )
Additionally, I have applied one logic, 2 columns will display only for those taxonomies who are assigned in multiple post types, for example, if any taxonomy assign only in 1 post type then it will not display 2 columns.
#36
in reply to:
↑ 33
@
16 months ago
Replying to audrasjb:
Maybe we can have only one column and add a count per post type below the overall count?
Yes, I did try but UI looks odd, you can see my above screenshot( https://core.trac.wordpress.org/raw-attachment/ticket/32942/New%20Project.png ) and on hove any count value title attribute display the specific title.
#37
@
16 months ago
- Focuses ui added
- Keywords has-patch added; needs-patch 2nd-opinion needs-design-feedback needs-design removed
#39
@
16 months ago
Test Report
Environment
- 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz 2.42 GHz
- Chrome 114.0.5735.199
- Server: nginx/1.25.0
- PHP: 8.2.0
- WordPress:6.3-beta4-56216-src
- Theme: Twenty Twenty-Two
Expected Results
It will display a separate column for the current post-type posts count.
✅ Working as well.
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.