WordPress.org

Make WordPress Core

Changes between Initial Version and Version 3 of Ticket #40510


Ignore:
Timestamp:
03/08/2018 08:12:16 PM (3 years ago)
Author:
flixos90
Comment:

Per today's REST API chat, supporting pagination and generally allowing a bit more flexibility with the revisions controller would also come in handy for Gutenberg.

40510.diff adds support for the following query parameters for revisions:

  • exclude
  • include
  • offset
  • order (default 'desc')
  • orderby (default 'date')
  • page (default 1)
  • per_page (default not provided, falling back to using -1 with WP_Query, meaning no limit, for BC with current behavior)
  • search

The implementation aligns closer with how the posts controller works. WP_Query is directly used instead of calling wp_get_post_revisions(), to be able to run a SELECT FOUND_ROWS() query and get the result. Since the function is only a simple wrapper for a query object anyway which sets default arguments, this can easily be handled in the controller itself.

The revisions controller will now return X-WP-Total and X-WP-TotalPages headers and pagination link headers (if applicable) for collection requests, just how the posts controller does.

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #40510

    • Property Keywords has-patch needs-unit-tests added
    • Property Owner set to flixos90
    • Property Status changed from new to assigned
    • Property Milestone changed from Awaiting Review to 5.0
  • Ticket #40510 – Description

    initial v3  
    1 The post revisions REST endpoint currently has no support for pagination. While it works well for most usages with fairly low counts of revisions (Wordpress.com limits the number at 25 for instance), on posts with a revision count in the hundreds (or even thousands), this can quickly yield unreasonably large (Mb+ of pure text) and long (several seconds on my "test" instances) responses.
     1The post revisions REST endpoint currently has no support for pagination. While it works well for most usages with fairly low counts of revisions (WordPress.com limits the number at 25 for instance), on posts with a revision count in the hundreds (or even thousands), this can quickly yield unreasonably large (Mb+ of pure text) and long (several seconds on my "test" instances) responses.
    22
    33The API already supports pagination for a vast majority of ressources (posts, pages, categories, tags, users) and is normalised around using 2 integer parameters: `page` (default: `1`)and `per_page` (default: `10`).