REST API JS Client: currentPage should be set to the "paged" filter variable

[adamsilverstein]

Moving this issue over from Github: ​https://github.com/WP-API/client-js/issues/133

peterigz commented on Aug 23:

If you fetch a post collection and use the "paged" filter variable to get a certain page, then when using .more() it will fetch the same page over and over again because the requestfilter? variable is merged with the $args variable in the rest controller WP_REST_Posts_Controller::get_items therefore overwriting/ignoring the requestpage? value.

So I think that the state.currentPage should be set to "paged" if it exists and then delete the "paged" variable from the filter so .more() then works as you'd expect. I'm doing this manually as a work around and it works fine but maybe this can be considered a bug?

[rachelbaker]

@adamsilverstein or @kadamwhite any volunteers to own this for 4.7?

[kadamwhite]

+1, that bug should definitely be addressed. I can't take any action until the weekend at the earliest but I'll pick it up then if @adamsilverstein hasn't grabbed it first.

[adamsilverstein]

I will take a look soon!

[adamsilverstein]

@peterigz Thanks for the bug report.

I tested this and verified the client currently performs as expected if you use the 'page 'option', capturing the passed page parameter if you use it, and storing that in the collection state.currentPage. In your report you mentioned that you use the "paged" filter variable which may be the source of the problem, that method is not supported.

Here is the correct way to use the page option with the api collection objects, I will update the docs reflect this usage:

// Load the posts collection.
var posts = new wp.api.collections.Posts(); 

// Load page 5.
posts.fetch( { data: { page: 5 }  } )
	.done( function() { 

		// This loads page 6.
		posts.more();
	} );

I loaded up 100+ dummy posts and verified this works correctly at the console:

Thanks again for testing, closing as invalid.