Caddy and WordPress Rest API

Help
1

I’m using Caddy for a WordPress site without problem for several months (so first, thanks for this !).

Recently however, I noticed a problem with the Rest API which is more and more used in WordPress. I noticed the search through the Rest API is not correct. I always have the latest posts instead of search results, which is the default if you provide no argument for search.

Furthermore, If I add parameter to the search beyond just a keyword, the operation fails and I have a 400 error. I think, without certainty, it is linked to Caddy and the necessary rewrite for WordPress. Here’s the relevant part of my caddyfile :

rewrite / {
	if {path} not_match ^\/wp-admin
	to {path} {path}/ /index.php?_url={uri}	
}

I tried to exclude URL with wp-json as well, but then I have a 404 sent by Caddy.

Here’s an example of the search giving latest posts instead of relevant ones : https://voiretmanger.fr/wp-json/wp/v2/posts?search=nolan

And here’s one giving a 400 error : https://voiretmanger.fr/wp-json/wp/v2/posts?search=nolan&per_page=20&orderby=relevance

I checked logs, both for Caddy and php-fpm, but found nothing.

2

No one ? :frowning_with_open_mouth:

If someone is using Caddy and latest WordPress version : could you try a search using the REST API ?

Here’s the syntax :

https://domain.com/wp-json/v2/posts?search=word

You should have relevant posts. If you see latest posts by order, then you have the same bug as me.

Thanks if you can help me ! :+1:

3

Hello - if possible are you able to remove Caddy from the mix here to prove that it is somehow responsible?

Also you said that if you add any parameters other than just the keyword it fails - I tried this URL (blind guess) and I got a JSON response:

https://voiretmanger.fr/wp-json/wp/v2/posts?search=nolan&per_page=20&orderby=id

That combined with your comment made me wonder whether the rewrite is working correctly at all …

The {uri} placeholder as per the Caddy docs https://caddyserver.com/docs/placeholders is “The request URI (includes path, query string, and fragment)” which suggests that maybe your rewrite is rewriting it to /index.php?_url=/wp-json/wp/v2/posts?search=nolan maybe with the two ? separators. The Caddy docs say there is a {uri_escaped} placeholder that you can use - give that a go maybe?

It’s hard to fully debug when I don’t have a Wordpress site to play with, but these suggestions may point you in the right direction. Let me know how you get on.

Cheers,

Bob.

1 Like
4

Thanks for your help ! :+1:

Unfortunately, I have no easy way to try without Caddy, I have a server without ngninx or Apache…

But you’re right that the rewrite is the problem. I tried the {uri_escaped}which I didn’t know, but it prevents search to work at all, all REST API requests display the last posts, as if I had not made any search.

I think though the answer is here somewhere.

EDIT : I don’t think it could help, but here’s what I have on the log side :

5.51.108.59 - - [20/Aug/2017:08:47:13 +0200] "GET /wp-json/wp/v2/posts?search=nolan HTTP/2.0" 200 29597
5.51.108.59 - - [20/Aug/2017:08:47:35 +0200] "GET /wp-json/wp/v2/posts?search=nolan&per_page=20&orderby=relevance HTTP/2.0" 400 143
5

Would you mind logging the {rewrite_uri} while rewriting to {uri_escaped} so we can see exactly what the result of Caddy’s rewrite is?

log / access.log "{common} {rewrite_uri}"

6

Here’s what I have :

109.26.10.26 - - [21/Aug/2017:13:38:37 +0200] "GET /wp-json/wp/v2/posts?search=nolan HTTP/2.0" 200 28686 /index.php?_url=/wp-json/wp/v2/posts?search=nolan
109.26.10.26 - - [21/Aug/2017:13:39:26 +0200] "GET /wp-json/wp/v2/posts?search=nolan&per_page=20&orderby=relevance HTTP/2.0" 400 143 /index.php?_url=/wp-json/wp/v2/posts?search=nolan&per_page=20&orderby=relevance
7

Hrm, well. That is a perfectly legal query string, I suppose.

Out of curiosity, why are we rewriting to include ?_url={uri} anyway? I can’t for the life of me find out where it’s documented to use this format, even though I’ve seen a number of people use it.

I mean, the Apache htaccess rewrites just to index.php, and the NGINX-specific documentation rewrites to /index.php?$args, the Caddy equivalent of which is /index.php?${query}, which matches the example from Caddy’s WordPress example on GitHub: examples/Caddyfile at master · caddyserver/examples · GitHub - so where does the _url paramenter come from?

1 Like
8

Well, it was the old way until June the 27th… Fix WP rewrite for jetpack (closes #71) · caddyserver/examples@7c81755 · GitHub :slight_smile:

I’ll try this method instead as soon as possible !

1 Like
9

It works great this way ! :+1:

Thanks for your help. :slight_smile:

1 Like
10

Awesome, glad to hear! Thanks for that link, too.

Let us know if there’s any more weirdness with this method!

11

So far, I have noticed one other bugfix using WordPress : now I can edit a published post and preview my edits in a different window. Until now, I had to publish changes to see them online.

As far as I’m concerned, it’s a great change. I’m glad the example on GitHub was changed, WordPress support is really better that way.

1 Like