To explain my problem, I need to give a bit of background: One of my web projects consists of an infrastructure that has evolved over the last 25-or-so years. Three examples (the domain is made up, of course): mydomain.tld is my homepage, so to speak, mydomain.tld/blog is a WordPress installation, and mydomain.tld/projects/ is a folder structure made up of all sorts of hand-coded subpages that I would like to leave as they are. I’ve realised that I could, in principle, migrate mydomain.tld entirely to Kirby, with the exception of certain parts of /projects. How do I need to configure Kirby (or my web server? I use Caddy) so that mydomain.tld points to a Kirby installation, but mydomain.tld/projects works completely without Kirby?
(If that’s too complicated, I’ll stick to my original plan of “only” rebuilding /blog in Kirby.)
This will less depend on your Kirby setup itself but more on your web server, e.g. your Caddyfile.
I am not that fluent with Caddy, but probably something like
mydomain.tld {
handle_path /blog/* {
root * /var/www/wordpress
# ...
}
handle /projects/* {
root * /var/www/legacy
# ...
}
handle {
root * /var/www/kirby
php_fastcgi unix//run/php/php-fpm.sock
file_server
}
}
handle_path strips the matched prefix, which is what you want for WordPress rooted in its own directory. Plain handle keeps it, so /projects/foo/ resolves to /var/www/legacy/projects/foo/. Pick whichever matches how things sit on disk.
Watch out for path collisions. Any prefix you carve out is invisible to Kirby, the first handle block in the Caddyfile grabs the request, so in this example blog/* and projects/* paths never reach Kirby. So don’t create a Kirby page with the slug projects or blog, they would be unreachable. Same goes for the paths Kirby uses itself (media, panel, api, content, site, kirby, assets). Make sure you don’t block those.
Thank you, that was exactly what I needed to know. 