Move /posts WP_Query vars to filter param
#1420
Conversation
Currently, `/wp/v2/posts` allows WP_Query params and a few of our own "per_page" etc. This is confusing and inconsistant. I think we discussed a while back that we'd put all the WP_Query (internal) named collection params under a `filter` param (inspired by v1) and implement standardized collection params for posts that's inline with the params for `terms`, `users` and `comments`.
|
👍 on the concept. Right now, having the raw WP_Query vars is a bit confusing. |
|
I think I started but never completed this in #1302. It might be worthwhile to just finish that branch |
|
Why only do this for |
There was a problem hiding this comment.
I always thought paged and posts_per_page being outside of the filter argument was weird. If we are going to move the WP_Query args to the filter array we should move them all!
There was a problem hiding this comment.
@rachelbaker I did move them all :) this is mapping page and per_page to WP_Query vars.
There was a problem hiding this comment.
filter is only for WP_Query arguments. page and per_page are our new, consistent with the rest of the controllers, arguments.
As @joehoyle noted, "Feedback on this before I go further I think :)", so probably just proving it out with posts first. |
One problem with not doing it for the others is that we don't know which variables can be public, since there's no analog to I'm going to merge this for now, since the others already use our custom mapping. If we want to add the ability to get at the underlying |
|
Looks good to me |
Move /posts WP_Query vars to `filter` param
Currently,
/wp/v2/postsallows WP_Query params and a few of our own"per_page" etc. This is confusing and inconsistant. I think we discussed a
while back that we'd put all the WP_Query (internal) named collection params
under a
filterparam (inspired by v1) and implement standardized collectionparams for posts that's inline with the params for
terms,usersandcomments.Feedback on this before I go further I think :)