Inconsistent Post Count in Category Taxonomy

[phunsanit]

Description

There is a discrepancy between the post count displayed in the Category List (edit-tags.php) and the actual number of posts displayed when clicking through to the Post List (edit.php?category_name=...).
Environment

Platform: WordPress Admin Dashboard

Affected Pages: * /wp-admin/edit-tags.php?taxonomy=category

/wp-admin/edit.php?category_name=history

Steps to Reproduce

Create a category named "History".

Publish 1 post assigned to the "History" category.

Create a 2nd post assigned to the "History" category, but set its status to "Scheduled" (Future).

Navigate to Posts > Categories (edit-tags.php). Observe the Count column for "History".

Click the count number (1) to view the posts in that category.

Expected Result

The count in the Category List should reflect the total number of items managed within that category (2), or the Post List should filter by "Published" by default to match the count.
Actual Result

Category List: Displays a count of 1 (only counting Published posts).

Post List: Displays 2 items (1 Published + 1 Scheduled).

Note: There are no active filters applied in the Post List, yet the numbers do not align.

Suggested Fix/Reasoning

The internal function _update_post_term_count() currently only includes the publish post status. To improve UX and consistency for site administrators, the update_post_term_count_statuses filter should be utilized to include the future status in the count calculation.
A Quick Technical Note

Since you mentioned earlier that you don't have a "Published" filter active, WordPress's default behavior is to show all statuses you have permission to see (Draft, Scheduled, Published) on the edit.php screen, which is why the "2" appears there while the "1" stays on the category summary.

Would you like me to provide the specific PHP code snippet to fix this so your "Scheduled" posts are always included in that count?

[phunsanit]

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

[phunsanit]

/wp-admin/edit.php?category_name=history

https://core.trac.wordpress.org/ticket/64853

[maulikmakwana2008]

Correct patch category-count-fix.patch

I have attached a patch that modifies wp-includes/taxonomy.php to include the future post status in the default term count calculation.

Reasoning:
Currently, there is a UI inconsistency between edit-tags.php (which shows only published posts) and edit.php (which shows all statuses the user has permission to see). This leads to confusion for administrators who see a count of '1' in the Category list but '2' items when clicking through to the Post list.

Changes:
Updated the $post_statuses array in _update_post_term_count() to include 'future'. This ensures that scheduled content is reflected in the taxonomy counts, providing a more accurate representation of managed content within the Admin Dashboard.

Considerations:

Database Update: Existing counts will not update immediately upon applying the patch; a term recount or post update is required to sync the database values.

Front-end Impact: This will cause categories containing only scheduled posts to no longer be considered 'empty.' While this fixes the Admin UI, developers using hide_empty => true in front-end queries should be aware that these terms will now appear, potentially leading to 'No posts found' messages if the theme does not handle empty loops gracefully.

I've tested this locally, and it successfully aligns the counts once a post transition is triggered.

[shreyasikhar26]

Hey @phunsanit / @maulikmakwana2008

This inconsistency isn’t limited to scheduled posts; it can also occur with draft, pending, private or any other custom post statuses.

Also, WordPress has provided a filter update_post_term_count_statuses, by using it we can decide which statuses we can allow to update the term count.

Code reference: ​https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-includes/taxonomy.php#L4182

We can hook a callback into this filter within a theme or plugin to return all registered statuses—or just the specific ones needed. Let me know if you think this approach would work for your use case.