Should REST API support multiple orderby values?

[ChopinBach]

WP_Query features the ability to query by multiple orderby parameters as well as independent orderby parameters (https://core.trac.wordpress.org/ticket/17065). The API does not have this ability yet. I looked through GitHub issues to find any discussion regarding this and could not find any. Should the REST API also support multiple orderby parameters or is that deemed to be plugin territory?

[jnylen0]

What would it take to support this as a feature of the API?

Is it possible to make this work via existing filters? (This would also be a useful exercise to document adding orderby parameters via filters and determining whether there is anything left to be fixed there - see ticket:38693#comment:22 for a simpler case which we haven't tried yet)

[jnylen0]

Another question: do other object types (WP_Comment_Query etc) support this?

[ChopinBach]

Replying to jnylen0:

Is it possible to make this work via existing filters?

Implementing multiple orderby values is not too difficult to implement. Doing the independent variation where some fields are ASC and some DESC would be considerably harder to put into the API. I am pretty sure you can do both by using multiple filters in the API.

Another question: do other object types (WP_Comment_Query etc) support this?

From a quick look, it appears that only the standard WP_Query object supports multiple and independent orderby parameters.

[ChopinBach]

WP_User_Query does support multiple orderby parameters.

[David_sa]

Any progress on this?

Fixes https://core.trac.wordpress.org/ticket/39037 to add multiple orderby values to the REST posts controller.

### Problem

When sorting by a single dimension such as menu_order many items may be equal to one another. Currently we don't provide or intend to provide a stable sort for those equal items. To avoid this we commonly provide a second dimension to sort by like title, which currently isn't possible in the API.

Internal implementation details also affect ordering, sometimes in surprising ways. One example is simply changing a limit from 499 to 500. At a limit of <500, WP_Query internally splits a post query into two queries: issue, changeset.

API usage in the block editor limits per_page to 100 per request, so in many cases the order fetched by the client and one created in a block render_callback will not match.

​https://user-images.githubusercontent.com/1270189/114452136-f7cbfe00-9b8c-11eb-86ac-492eba6052ec.mp4

### TODO

• [ ] Audit affected filters
• [ ] Smoke test other affected rest endpoints

### Testing Instructions

• Verify that tests pass and make sense
• Manually test with a few requests in the following format:

  /wp/v2/pages?per_page=100&orderby=menu_order&order=asc
  

  /wp/v2/pages?per_page=100&orderby=menu_order,title&order=asc
  

  /wp/v2/pages?per_page=100&orderby[]=menu_order&orderby[]=title&order=asc
  

  /wp/v2/pages?per_page=100&orderby[menu_order]=asc&orderby[title]=desc
  

If folks don't have an rest client handy, we can open the console when visiting the post editor:

wp.apiFetch( { path: '/wp/v2/pages?per_page=100&orderby[menu_order]=asc&orderby[title]=desc' } ).then( ( data ) => { 
    console.log( data );
} );

Reading through https://core.trac.wordpress.org/ticket/47642#comment:13 it looks like folks do prefer this at the WP_Query level. I’ll back out the other commits from this PR

I circled back to this one and it's ready for another look 👀 In terms of feedback I have two main areas that would be helpful:

#### Affected Filters

There are two filters that now have breaking changes. What do folks think might be the best way to resolve this?

• rest_query_var-orderby ​https://developer.wordpress.org/reference/hooks/rest_query_var-key/ Breaking Change $value used to be string, but can now be array or object)
• ​https://developer.wordpress.org/reference/hooks/rest_this-post_type_query/ Breaking Change $value['orderby] used to be string, but can now be array or object)
• ​https://developer.wordpress.org/reference/hooks/rest_this-post_type_collection_params/ (updated orderby schema, change looks okay).

#### Any missing test coverage?

Are there any areas that I should add tests / verify changes for?

cc @TimothyBJacobs @mdawaffe or whomever may be interested

I think test failures here mean that fixtures need to be regenerated for tests/qunit/fixtures/wp-api-generated.js Do folks know what command should be run here?

I think test failures here mean that fixtures need to be regenerated for tests/qunit/fixtures/wp-api-generated.js Do folks know what command should be run here?

Running the rest api phpunit test suite should regenerate those files. --group restapi

[pbiron]

I would love to get this implemented. I'm building a custom block that calls ​useEntityRecords() and I need (actually it's a want, but it's pretty close to need ;-) to use a multi-level orderby ('menu_order title').

I suspect that once the REST API supports multi-level orderby, various things in GB will need to then be modified to support the feature.

[Mamaduka]

I see this ticket in the @todo comment occasionally in the Gutenberg code. One such example is the Page List block.

@TimothyBlynJacobs, can you confirm if the original patch was moving in the right direction? I'm happy to commit my time and get this over the finish line.

I suspect that once the REST API supports multi-level orderby, various things in GB will need to then be modified to support the feature.

@pbiron, GB just sends and receives REST API requests as they are. I don't think it will need any modifications.

[pbiron]

Replying to Mamaduka:

I suspect that once the REST API supports multi-level orderby, various things in GB will need to then be modified to support the feature.

@pbiron, GB just sends and receives REST API requests as they are. I don't think it will need any modifications.

Sorry, I should have been more clear in my comment.

As a simple example, consider the Latest Posts (or Query Loop) block. There is currently an orderBy param. Corresponding to that param, there is a select/dropdown in block properties UI.

If/when the REST API supports multi-level orderBy, the GB UI (for specific blocks) will need a way for content editors to specify a multi-level orderBy.

Unfortunately, I don't currently have any bright ideas about what those UI changes could/should be :-) and would be perfectly happy (at least on 1st release) with having to go into Code Editor mode to specify a multi-level orderBy.

Does that make sense?

[Mamaduka]

@pbiron, you're right. The Query Look block UI will need to be adopted to support multi-level orderBy values.

I also don't know what the best UI for this case is; maybe a repeater pattern (an example can be found in Global Styles -> Shadows). I guess we'll cross that bridge when REST API supports the argument.