#38378 closed defect (bug) (fixed)
Remove the `filter` parameter in the Post Controller
Reported by: | websupporter | Owned by: | rachelbaker |
---|---|---|---|
Milestone: | 4.7 | Priority: | normal |
Severity: | normal | Version: | 4.7 |
Component: | REST API | Keywords: | has-patch needs-refresh |
Focuses: | Cc: |
Description
As discussed in https://github.com/WP-API/WP-API/issues/2799 the team decided to drop support for the filter parameter. It introduced an "inconsistent mess" and "exposing WP_Query through filter has and will continue to be difficult to support."
Attachments (3)
Change History (12)
#3
@
8 years ago
Our calculation of the max. pages needed posts_per_page
to be set in our $query_args
. In order to overwrite filter
we did so before. When I deleted the filter
stuff, I also deleted this, which produced a bug.
Since we always make sure, we add stuff only, when it is given in the schema like
<?php if ( isset( $registered['per_page'] ) ) { $args['posts_per_page'] = $request['per_page']; }
I thought it might not be the best to rely on posts_per_page
is set. In 38378.2.diff I use the $posts_query->query_vars
instead:
$max_pages = ceil( $total_posts / (int) $posts_query->query_vars['posts_per_page'] );
This ticket was mentioned in Slack in #core-restapi by kadamwhite. View the logs.
8 years ago
#5
@
8 years ago
Technically if somebody has de-registered per_page
as a valid parameter, they're probably extending this to write their own endpoint and have voided their pagination warrantee in the process. I'm not sure it makes sense to me to special-case this, when so many other properties that the API depends upon for proper functioning are whitelisted in the same general way using $registered
. I would defer to @rmccue and @joehoyle on this, though.
Will update the patch. Lines 169-170 need to be included.