[wp-trac] [WordPress Trac] #29745: Post count incorrect for shared custom taxonomy in context of post type

[WordPress Trac]

#29745: Post count incorrect for shared custom taxonomy in context of post type
--------------------------+------------------------------
 Reporter:  jchristopher  |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Taxonomy      |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  administration
--------------------------+------------------------------
Description changed by SergeyBiryukov:

Old description:

> ''I found other tickets that may tackle a variation of this issue, but
> they seem to focus on'' `post_status` ''as opposed to'' `post_type` ''—
> hoping this isn't a dupe of the following:''
>
> https://core.trac.wordpress.org/ticket/24305
> https://core.trac.wordpress.org/ticket/18072
> https://core.trac.wordpress.org/ticket/14073
> https://core.trac.wordpress.org/ticket/13670
>
> ----
>
> I have a custom taxonomy (`collection`) that I'm sharing among two custom
> post types (`product` and `lookbook`).  Products are part of a
> Collection, and each Collection has a Lookbook, so each 'lookbook' shares
> a 'collection' term with a 'product'.
>
> I believe there's a bug concerning the Count when viewing the Collections
> term list when in context of Products vs. Lookbooks.
>
> For example, I have created a single `product` with a `collection` term
> of 'Fall':
>
> [[Image(https://mondaybynoon.com/images/wp-trac/screenshot-1.png)]]
>
> When viewing Collections under the Products CPT menu, the Count column is
> accurate:
>
> [[Image(https://mondaybynoon.com/images/wp-trac/screenshot-2.png)]]
>
> However (even though I haven't added any Lookbooks yet) when I view
> Collections under the Lookbooks CPT menu I assume that these counts will
> represent the counts of that CPT ('lookbook'), but it appears to simply
> retrieve the count stored in the database, which is an overall count of
> term usage, not limited to any particular post type:
>
> [[Image(https://mondaybynoon.com/images/wp-trac/screenshot-3.png)]]
>
> Clicking the count brings you to a CPT listing page filtered down to the
> Fall `collection` term as expected, with no posts (expected), but the
> original count of 1 is incorrect:
>
> [[Image(https://mondaybynoon.com/images/wp-trac/screenshot-4.png)]]
>
> I've included a patch but would love to hear what you think about a
> better approach to this. I considered whether adjusting `get_terms()` to
> accept a `post_type` parameter was acceptable but it didn't seem like an
> appropriate place to make an adjustment like this.

New description:

 ''I found other tickets that may tackle a variation of this issue, but
 they seem to focus on'' `post_status` ''as opposed to'' `post_type` ''—
 hoping this isn't a dupe of the following:''

 #24305 #18072 #14073 #13670

 ----

 I have a custom taxonomy (`collection`) that I'm sharing among two custom
 post types (`product` and `lookbook`).  Products are part of a Collection,
 and each Collection has a Lookbook, so each 'lookbook' shares a
 'collection' term with a 'product'.

 I believe there's a bug concerning the Count when viewing the Collections
 term list when in context of Products vs. Lookbooks.

 For example, I have created a single `product` with a `collection` term of
 'Fall':

 [[Image(https://mondaybynoon.com/images/wp-trac/screenshot-1.png)]]

 When viewing Collections under the Products CPT menu, the Count column is
 accurate:

 [[Image(https://mondaybynoon.com/images/wp-trac/screenshot-2.png)]]

 However (even though I haven't added any Lookbooks yet) when I view
 Collections under the Lookbooks CPT menu I assume that these counts will
 represent the counts of that CPT ('lookbook'), but it appears to simply
 retrieve the count stored in the database, which is an overall count of
 term usage, not limited to any particular post type:

 [[Image(https://mondaybynoon.com/images/wp-trac/screenshot-3.png)]]

 Clicking the count brings you to a CPT listing page filtered down to the
 Fall `collection` term as expected, with no posts (expected), but the
 original count of 1 is incorrect:

 [[Image(https://mondaybynoon.com/images/wp-trac/screenshot-4.png)]]

 I've included a patch but would love to hear what you think about a better
 approach to this. I considered whether adjusting `get_terms()` to accept a
 `post_type` parameter was acceptable but it didn't seem like an
 appropriate place to make an adjustment like this.

--

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