Nested WordPress instances v2

Help
1

I had an interesting situation yesterday. I had to set up a site where there was a WordPress instance at the root, with two additional instances nested in subdirectories. I got to learn a bit about php_fastcgi.

I think the expanded form reference in the documentation should be changed. It shows named matchers defined inside a route block, and I don’t think that works.

Also, if anyone has any feedback on this, it would be appreciated. It’s working, after a lot of testing and tweaking. Maybe it will help someone else. It is a good idea to check out the php_fastcgi expanded form and tweak if for your own needs if php_fastcgi on its own can’t get the job done.

1 Like
2

Hi! Thanks for taking the initiative to try a bunch of things out, it’s motivating to see people experimenting with their config :smiley:

You’re right, currently the parser doesn’t handle named matcher definitions if they’re within a route. This is something we’ve known about but I’ll be honest I forgot about it when I updated the php_fastcgi expanded form. It’s tricky, because we want it to be readable top-down and if we pull the named matchers outside, it’ll be harder to understand what’s going on.

I think I’ll look into making a change (hopefully in time for v2.1) that allows named matchers to be defined within route, handle, and handle_errors blocks. I’ll leave the expanded form as-is in the docs in the meantime. It’s mostly meant to be an explanation of what it’s doing rather than an example to specifically take (but that should work too, you’re right).

Anyways, I think your Caddyfile can be significantly simplified, I don’t think you need to use the expanded form at all. The key to improving it is using the handle directive which lets you set up mutually exclusive request handling. The general idea is to do something like this (not certain it’ll work exactly like this but, worth a shot):

example.com {
	encode gzip
	log {
		output file /var/log/caddylog
	}

	root * /srv/wordpress

	handle /altsite1/* {
		root * /srv/wordpress/altsite1
		uri strip_prefix /altsite1
	}

	handle /altsite2/* {
		root * /srv/wordpress/altsite2
		uri strip_prefix /altsite2
	}

	php_fastcgi unix//var/run/php/php-fpm.sock
	file_server
}

The idea is you’ll handle the sites in subpaths separately, strip the URL prefix, then override the site root. The php_fastcgi handler just needs the path and root to align once it’s its turn to run. You need to strip the path prefix, because otherwise that prefix would be appended to the root when the try_files in php_fastcgi looks for files, and it won’t work correctly in that case.

2 Likes
3

Early on in the process of making this config, I tried something similar, but not exactly the same. I had this weird issue where the wp-admin would redirect back on itself, which lead me to the overly verbose expanded form.

If I get the chance to try this simplified approach, I will. I wasn’t using handle when I tried this earlier, so that may be the key to getting the simpler approach to work.

1 Like
4

I’ll just mention - I think there’s some room for improvement with how php_fastcgi does the try_files, especially for situations like yours. I think what it should actually do is for some request like:

GET /some/path

Is try files like this:

try_files {path} /some/path/index.php /some/index.php index.php

Specifically, it would need to try each path segment, in order of deepest to shallowest. That way, you wouldn’t even need the handle, and it would just work out of the box with php_fastcgi. :thinking:

This is just some thinking out loud, no promises. I might look into seeing if something like that is possible.

1 Like
5

I’m glad this brought up a valuable line of thought.

1 Like
6

This topic was automatically closed after 30 days. New replies are no longer allowed.