I’m running a Wordpress blog on a subdirectory. The front page loads great, as does wp-admin, but when I try to open any link with a further url element in it, caddy gives me a 404 error. So domain.com/blog/ works, but domain.com/blog/post-name and domain.com/blog/year/month/ do not.
I imagine there’s a bit of regex which would solve this problem where caddy thinks I’m asking for an existing directory and isn’t rewriting to index.php!
We can test whether this is actually the case. The log directive can be configured to provide other placeholder information for a given request.
Override the log format on the second site definition to provide the {rewrite_uri} placeholder and you can find out which file Caddy is actually 404-ing on:
I’ve got Wordpress blogs on their own domains which are working fine on this server, so it’s clearly a problem related to the fact that it’s on a subdomain - but it could well be a Wordpress problem, not Caddy’s.
Your site address is domain.com/blog, and you’re rewriting from /blog. It’s possible that the rewrite isn’t even going off unless the client browses to domain.com/blog/blog.
Change rewrite /blog { to just rewrite { to change it into a catch-all, since you don’t need to specify the base path (as the site address requires that path to match in the first place).
Quick edit: I am making the assumption that the directories requested don’t actually exist on disk, e.g. /var/www/domain.com/blog/2018/10/ is not a real folder.
Yes, your assumption is correct, they’re generated as part of Wordpress’s pretty permalinks.
Progress! I’ve changed rewrite /blog { to rewrite { and lo and behold, these fake directory paths work! Sadly, there’s now a different problem, which is that images, .css and .js files (presumably any really existing file) are no longer loading, despite definitely existing in the file tree. Here’s the kinda fascinating access log:
It appears to be treating the automatic version numbers Wordpress appends to the .js and .css files as the file names themselves, but also ignoring the fact that they exist as real files? (I’ve changed the rewrite rule to to {path} {path}/ /index.php?{query} which is working in my other Wordpress setups).
For reference, some of the access log for one of the working setups is as follows:
This is the expected rewrite result of /index.php?{query}. The query string for the request /blog/wp-includes/css/dist/block-library/style.min.css?ver=5.0.2 would be ver=5.0.2, so the rewrite should result in /index.php?ver=5.0.2, which is the result we got. The issue is that we get that result instead of having the rewrite stop at {path}, since it should exist.
Just to confirm, /var/www/domain.com/blog/wp-includes/css/dist/block-library/style.min.css does exist? You can stat that path?
I’d put money that the reason this is the case is that the rewrite never fires in this scenario.
I’m pretty sure this has to do with the way Caddy handles site addresses that include paths and how the directives translate (or don’t translate) that path prefix.
You can try combining the two into a single site address with no path. This will be pretty easy to test because the /blog web root exists directly under the main site’s web root; you just need to overload the rewrite so that it prepends /blog for blog requests that get rewritten.