REST API wrong total pages

[elvishp2006]

When I require posts with the draft status the 'x-wp-total' and 'x-wp-totalpages' headers come with extra values ​​being that not all drafts are from the user making a request, so when I try to pick up the second page the answer comes empty.

[schlessera]

To make this work, I think WP would need to make two separate queries when checking for draft posts and published posts at the same time.

So, the logic would be:

If status includes draft:

• remove draft from status and run query
• run second query for draft status where the author is the current user
• sum the count of both queries

@timothyblynjacobs mentioned that this might not work as expected due to capability checks, though.

[wongalex]

I can take a look at this as my first real bug and get a diff for the above out (assuming, everything functions and it fixes the total pages).

[TimothyBlynJacobs]

#49187 was marked as a duplicate.

Trac ticket: https://core.trac.wordpress.org/ticket/42947

[TimothyBlynJacobs]

I spent some time digging on this. The root cause of this issue is that a post being returned from WP_Query is not a guarantee that it will be included in the response because the current user might not have permission to read it.

We can't really do separate queries, because we can't paginate over two separate queries.

So I would say that clients should be prepared to handle responses that have less results than a full page. Additionally, they should continue to paginate as long as their is a next link, even if that page is partial or empty.

However, WP_Query does support a perm argument which can check attach a post_author clause if the user doesn't have the permissions to read/write that post status. WordPress applies this in the admin list tables using wp_edit_posts_query().

This only applies to statuses that are marked private. So it doesn't include drafts which are marked as protected, so this wouldn't help with your problem in particular, but would still be an improvement nonetheless.

The only potential issue is that this means that posts that have granted read/edit capability to posts marked private using map_meta_cap wouldn't appear in the collection endpoint by default. I don't think this is a significant issue since the same thing applies in the admin list tables. Note, the post would still be accessible via it's single get_item route.

I've opened a PR that implements that behavior.

[hellofromTonya]

In talking with Timothy, moving this ticket into 5.7 and marking as early to get it into the cycle as early as possible and give more attention to it early on.

[chaion07]

From the [discussion]​https://wordpress.slack.com/archives/C02RQBWTW/p1618946568378600 during our recent bug-scrub, we consulted that this ticket needs a refresh since it does not apply cleanly anymore

[desrosj]

This has not seen any progress during the 5.8 cycle, so punting to 5.9.

[audrasjb]

patch refreshed against trunk

[TimothyBlynJacobs]

I'm moving this to a Future Release, there are some other moving parts that need to be looked at before this can be committed.