.pages().slug('foo').update error - `rest_no_route`

[benfoxall]

Hey @kadamwhite - this is the issue that I mentioned yesterday.

I expected to be able update the content of a page with this:

wp.pages().slug('my-page').update({content: 'new content'})

But it looked like .update wasn't a function. I ended up using a pretty ugly work around - though I'd love to know how to remove it.

There's a good chance I'm doing this wrong!

[kadamwhite]

Something's definitely going wrong here, because that method exists in a reduced test case I put together. @benfoxall Can you clarify how the wp object is being created? Are you using auto-discovery, or the out-of-the-box new WPAPI()?

[kadamwhite]

@benfoxall Also, what version of the library are you using?

[benfoxall]

I'm creating the client with new WPAPI() with endpoint/username/password properties (using the basic-auth plugin). I went down the manual route because I was trying to get this to work with wordpress.com originally.

I'm using version 1.0.2.

I'll be revisiting this code tomorrow, I can try updating to 1.0.3 & using auto-discovery.

[benfoxall]

Apologies - I had the error wrong. It's not function undefined - the promise fails with the following:

{
  code: 'rest_no_route',
  message: 'No route was found matching the URL and request method',
  data: { status: 404 }
}

I've uploaded a test case to my repo. I'm going to try and update the library and use auto-discovery now

[benfoxall]

I've updated to 1.0.3 and updated my test case to use auto-discovery. And I still get the same 404 error response.

[kadamwhite]

d'oh, I figured it out; sorry for the delay, I was chasing the wrong problem. .slug() is working correctly, but the result of any search operation (and searching by slug counts) is an array of posts, not a post object. So, to update this resource, you'd need to make two hops:

autodiscoveryPromise
	.then(wp => {
		wp.pages().slug('my-thing')
			.then((matchingPages) => {
				// matchingPages will be an array of length 1
				if (!matchingPages.length) {
					throw new Error('no page found for that slug');
				}
				return matchingPages[0];
			})
			.then(page => wp.pages()
				.id(page.id)
				.update({content: 'This is test content'})
			)
			.then(
				() => console.log('Completed'),
				e  => console.error(e)
			);
	});

(edited slightly from original posted snippet to make order of operations clearer)

The critical part is to read out the ID of the post from the returned array containing the match for the provided slug, because that post object is where you're going to find the ID you need to make the update (PUT) request. The URLs that can be used to uniquely address pages all depend on ID.

[kadamwhite]

I'm going to close this out because it does look like things are working as they must given the structure of the REST API, but if there's a specific improvement you'd like to see made to the docs to prevent this type of issue please suggest it and I'll re-open the ticket to cover implementing that docs fix. Sorry for the delay, @benfoxall, and thank you again for raising the issue.