I do PHP development in WSL (Windows System for Linux) on Windows 10, and currently use the built-in PHP dev server, but it is incredibly limited and you need to run different apps on different ports - and there isn’t TLS support afaik. I’m wondering if using Caddy as a local dev server would solve these issues and generally be nicer to work with. To configure it all properly, I’d need to manually edit the Caddyfile and Windows hosts file for each app I want to run. While not tricky, it does take some level of effort so I’m thinking of trying to script it.
Rather than write my own scripts, I thought I should ask in here first, to see if there is already something available I can use and potentially contribute to?
Then I start projects in ~/Projects/www/[projectname]. When I open http://projectname.test in the browser, Caddy rewrites its way into that directory and resolves any PHP via fastcgi.
This way I never need to rewrite Caddyfile, or restart Caddy. I just add or remove project folders.
I finally got a chance to test this out, and have a new problem.
The path that is passed into php-fpm is based on the global root, not the subdomain root. As such the application (in this case WordPress) includes the folders when generating URLs.
The simplest example is this from phpinfo. For my default site, the files are in /home/valorin/dev/default/public/, and I’m accessing it as https://pengwin.valorin.dev/:
What I need is for the /default/public to be stripped out of SCRIPT_NAME, DOCUMENT_URI, PHP_SELF, and DOCUMENT_ROOT to be pointing into the proper folder.
This is my config:
*.valorin.dev {
root /home/valorin/dev
index index.php index.html
fastcgi / /run/php/php7.3-fpm.sock php
tls {
dns cloudflare
}
log /home/valorin/dev/logs/access.log
errors /home/valorin/dev/logs/error.log
rewrite {
to /{label1}/public{uri} /{label1}/public/index.php?{query} /default/public{uri}
}
}
Do you know if what I want can be done, and if so, how?
It looks like fastcgi is respecting the rewritten URI, which in your case is… inconvenient. Rewrites should really be hidden from the client, but the way WordPress generates its URLs is inadvertently exposing it.
I don’t think this can be changed, currently. I’d consider opening a feature request on the Caddy repository to have an option for fastcgi to pass the non-rewritten versions. In the meantime, I think you might have to configure WordPress sites manually in your Caddyfile.