Is Caddy running on your live site currently?
Right now, yes.
Great, can you give me a link to a post that is using /year/month/date/slug path?
You can try the link I suggested at first, so Will Hunting, Gus Van Sant - À voir et à manger. It never was a real URL, but the rewrite should work with this, and if I don’t use Caddy, the redirect works fine.
To be clear, the result should be Will Hunting, Gus Van Sant - À voir et à manger
To understand that line, read the rewrite docs and check the examples https://caddyserver.com/docs/rewrite.
/index.php?_url={url} is specific to wordpress. It may be different for other php apps/frameworks.
1 Like
I reread the page, but I can’t fully understand what it says… Why two {path} in a row ?
And does this interfere with the regex rewrite I’m trying to implement ?
I think it tries to rewrite multiple times if it fails.
In this case it tries to rewrite to the {path} then to {path}/ (notice the forward slash) and finally to index.php?_url={uri}
destinations… is one or more space-separated paths to rewrite to, with support for request placeholders as well as numbered regular expression captures such as {1}, {2}, etc. Rewrite will check each destination in order and rewrite to the first destination that exists. Each one is checked as a file or, if ends with /, as a directory. The last destination will act as default if no other destination exists.
OK, I don’t understand why WordPress needs this (maybe it’s just the slash at the end of the URL ?), but I get it.
I don’t think this rewrite would be a problem for my rewrite, though…
There is no log that could indicate what Caddy is trying to do when I open a URL with a date in it, by any chance ?
No problem !
{path} checks for file
{path}/ checks for directory
It can be any string but those are placeholders that translates to the request path. Suffixing with / indicates a check against the string as a directory.
Similar to Nginx try_files.
1 Like
OK, it makes more sense in a static environnement, of course…
Can you post your error.log as well? Maybe that has something useful.
I don’t think so… there’s only this line :
07/Jun/2016:19:01:04 +0200 [ERROR 502 /index.php] write tcp 164.132.41.174:443->62.210.215.115:43293: write: connection reset by peer
Edit: Nevermind this…Derp.
Try changing the order of the rewrite rules like this:
rewrite {
r ^\/([0-9]{4})\/([0-9]{2})\/([0-9]{2})\/(.*)
to /{4}
}
# Routing for WordPress
rewrite {
if {path} not_match ^\/wp-admin
to {path} {path}/ /index.php?_url={uri}
}
Maybe it makes a difference…
Wait a second…
Rewrite is for when you want
/mobile
to actually request
/mobile/index
I just realized we are using the wrong directive.
If the post on wordpress is stored on
index.php?_url=/2014/14/04/some-post
then how do we make /some-post know to look in /2014/14/04/some-post?
I don’t think Caddy can do that since the date is dynamic and so there is no way for it to know where to look. Can you change the post permalinks in the old posts?
If you did that and wanted old links containing dates to work you could then add
rewrite {
r ^\/([0-9]{4})\/([0-9]{2})\/([0-9]{2})\/(.*)
to /{4}
}
What that does is when it sees a path /2014/14/14/some-post it will then ask WordPress for /index.php?_url=/some-post
I apologize for not realizing this sooner…
Frankly, all this URL rewriting logic belongs in the web app, this isn’t the job of the web server. Sometimes I regret giving caddy the rewrite directive. 
</rant>
But rewrite does allow a lot more people to use Caddy. Not many WP users would switch to /index.php?_url= just to use Caddy. We like our pretty links!
But you’re right, what @nicolinux is trying to do here needs to be done on the WP side.
Right; which is why I added it. But it’s a failure of the web app - WordPress in this case, but there are countless others - to rely on the web server to do the logic of programming URLs. A web server should just shuttle bytes around, really.