WP_Posts_List_Table::get_views() doesn't allow the "Mine" counts to be filtered

[pbiron]

​WP_Posts_List_Table::get_views() calls ​wp_count_posts() to get the counts for the various post statuses.

It then computes the count for posts owned by the current user for use in the "Mine" view. That computation uses $this->user_posts_count which is computed in ​WP_Posts_List_Table::__construct() with custom SQL.

The problem is that if you hook into the ​wp_count_posts filter and alter the counts for each post status you can end up with a situation where the "Mine" count is very different than the sum of the post status counts.

For example, I've got a CPT where some (but not all) of the posts of that type are just "placeholders" for posts of another CPT. I hide those "placeholder" posts from the list table by hooking into ​request and altering the request that the list table uses. I then hook into wp_count_posts to adjust the counts by post status accordingly (e.g., don't count the "hidden" posts). This results in a situation that could be very confusing for users (see screenshot).

Thus, I suggest that a filter be added to filter the value of $this->user_posts_count.

[pbiron]

47640.diff​ adds 2 new filters:

• user_posts_{$post_type}_count
• user_posts_count

for filtering the number of posts authored by the current user.

For the use case described above, they could be used as follows:

add_filter( 'user_posts_myposttype_count', 'myposttype_mine_count' );
function myposttype_mine_count( $post_count) {
        global $wpdb;

        $query = "
                SELECT COUNT( 1 )
                FROM
                        {$wpdb->posts} LEFT JOIN
                        {$wpdb->postmeta} ON ( ID = post_id AND meta_key = %s )
                WHERE post_type = %s AND post_author = %s
                ";

        $query = $wpdb->prepare( $query, 'my_meta_key', 'myposttype', get_current_user_id() );

        return (int) $wpdb->get_var( $query );
}

where the presence of post meta with key my_meta_key tells me which posts to count (i.e., posts without it are the ones that are "hidden" from the list table).

[SirLouen]

@pbiron this feels like excesively specific for just one use case (Mine), wouldn't be better to add a setter method or a getter method with a single hook for user_posts_count?
4 years have passed, so I assume that you were able to sort this in another way.

Adds a user_posts_count filter to WP_Posts_List_Table so plugins can align the Mine view count with filtered list-table queries. The filter receives the post type and current user ID for context.

Includes regression coverage for the filter arguments and rendered Mine count.

## Use of AI Tools

AI assistance: Yes
Tool(s): OpenAI Codex
Model(s): GPT-5
Used for: Ticket and code analysis, implementation, and test drafting. The resulting changes were reviewed and validated with PHPCBF, PHPCS, and focused PHPUnit tests.

[arkaprabhachowdhury]

Opened [PR #12315](​https://github.com/WordPress/wordpress-develop/pull/12315) to address this ticket. Adds a user_posts_count filter to WP_Posts_List_Table so plugins can align the Mine view count with filtered list-table queries. The filter receives the post type and current user ID for context. Includes regression coverage for the filter arguments and rendered Mine count. The PR includes focused regression coverage, and its validation details are recorded in the PR description.

I picked this up because the ticket describes a concrete core behavior or edge case that remains relevant in current WordPress. The proposed change is intentionally scoped to the ticket and is submitted here for code review, with the technical discussion remaining on this ticket.

Hi @pbiron — thanks for the helpful suggestion, Paul. I’ve added the user_posts_{post_type}_count filter and included the user_id as an argument, alongside the generic user_posts_count filter, with regression coverage for both. I’ve also merged the latest upstream changes to resolve the conflict. The focused PHPUnit test passes with 1 test and 6 assertions, and the update is pushed to this PR. Please confirm if this matches the expected hook pattern.