Running multiple WordPress sites using a single FrankenPHP container

[binaryfire]

Hi all. In the docs, I see this config for running multiple sites:

app.example.com {
	root * /path/to/app/public
	php_server
}

other.example.com {
	root * /path/to/other/public
	php_server
}

Is this the best way to handle multiple WP sites with minimal resource usage? Regarding security - these sites are client sites which are all fully locked down. Clients don't have admin roles, can't upload plugins or themes, or modify any sensitive settings etc. They can only edit posts and pages, upload media etc. Public user registration is also disabled. It's very similar to multisite except using separate installs.

I'm trying to minimise server resource usage so running a separate container per client wouldn't be ideal.

I'm not using SSL - the sites are behind a NGINX load balancer which is handling SSL termination. AutoSSL etc will all be fully disabled. So I'm also wondering if there's an easier way to handle adding / removing sites than programmatically rebuilding the Caddyfile each time

[withinboredom]

In this particular case, you probably want to simply handle all requests to a respective folder and keep doing whatever you are doing for nginx.

Perhaps doing something similar to what we did at Automattic: have in your public folder an index.php that looks at the current domain, whether it is valid, then simply include "/path/to/$client/public/index.php"

[binaryfire]

@withinboredom Didn't realise you used to work at Automattic - cool! So correct me if I'm wrong, but this sounds like a similar setup to my Laravel multi-db multi tenancy solution. Where I check the host, then switch things (eg. db, storage dir etc) to the correct tenant based on domain. Except in this case it's not just the db, it's booting WP from an entirely different directory based on the host. Is that right?

How did you handle the domain mapping? I imagine some kind of db would be required to store domain -> $client mappings. And I'm assuming you'd want it cached with something like Redis, otherwise you'd be hitting the db on every request?

[withinboredom]

Well, in our case, most sites were part of the massive multi-site installation. We used sunrise.php to override domain mapping behavior. I can't remember exactly (I left a few years ago but I was working on that code for over 5 years), but if I do remember correctly, sunrise runs after cache/db setup, but before everything else. Thus we could query the db/cache for domain mapping information; at least we did it somehow, but I only very rarely found myself in that file and can't remember the exact techniques.

According to this ticket, it's also enabled via single-site. This is sparsely documented behavior because it is mostly used by hosting providers for exactly the reasons you are looking for (efficient use of disk space and easier management of hundreds/thousands/millions of installations).

In theory, you could have a single WordPress installation and simply set the database/wp-content directory based on the domain.

I recommend checking this out:

// Define the new directory path and URL
define('WP_CONTENT_FOLDERNAME', 'your_folder_name');
define('WP_CONTENT_DIR', ABSPATH . WP_CONTENT_FOLDERNAME);
define('WP_CONTENT_URL', 'http://example.com/' . WP_CONTENT_FOLDERNAME);

You'd have to set this pretty early (aka, sunrise.php) before plugins are loaded. Multisite makes this much easier to manage (since you need to run db migrations after upgrading WordPress), but it isn't a strict requirement anymore (business plans use a similar technique and aren't on the multisite).

In other news, it is annoying WordPress uses constants/request-specific static variables to do things because worker mode makes all the difference in the world, but it is simply impossible to get WordPress to handle it without huge hacks.

[withinboredom]

Nope, it runs before db setup as well. This is actually used by Automattic as well: https://wordpress.com/plugins/hyperdb and I highly recommend it.

[binaryfire]

@withinboredom Thanks! I've played around with HyperDB before but that was with switching dbs for multisite installs. Still ended up with a shared users table though.

Will give it a shot - I think I've got enough to go on now.