[wp-trac] [WordPress Trac] #42947: REST API wrong total pages

[WordPress Trac]

#42947: REST API wrong total pages
-------------------------------------------------+-------------------------
 Reporter:  elvishp2006                          |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  REST API                             |     Version:  4.9.1
 Severity:  normal                               |  Resolution:
 Keywords:  has-screenshots has-patch has-unit-  |     Focuses:  rest-api
  tests                                          |
-------------------------------------------------+-------------------------

Comment (by 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.

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