Multisite VS Multiple sites?

A client of mine does business in Ireland (.ie) and in the UK (.uk). As these locations are quite close together, we are happy to host both websites on a single server. Both websites will use the same codebase and theme, but will have different content.

It seems there are two ways I can go about this: A single WordPress installation with multisite enabled, or two separate WordPress installations. I’m not sure which to choose.

I understand that multisites usually come with the benefit of only having to manage a single WP installation, and update a single set of plugins, but surely these benefits are diminished with Trellis, as Trellis will be accessing the same repository and updating all plugins on deployment?

I’ve always been wary of the architecture of WP multisites so I’m hesitant to launch one now, but does anyone have reasons for, or against, using a multisite in this case?

Any advice on this would be appreciated. Thank you.

My experience with Multisite is limited, so take this with a grain of salt, but IMO unless your use case is pretty closely aligned with the purpose of Multisite (a network of sites with that have the capacity to share users, and an administrative layer that allows for site-wide management of plugins and themes) it introduces additional complexity for no, or next-to-no, additional benefit. If both sites in your example are going to be administered by the same team (either yours, or your client’s) it’s possible you’d see some benefit with Multisite: logging into the network could give those users access to both sites (although you could get this same benefit on separate sites by using some kind of SSO plugin too).

1 Like

Thanks for replying, and yes, I am thinking the same way. WordPress is messy enough already without the extra complexity, and as for the benefits you have listed:

  • Shared users: Not much of a benefit really. SSO plugin solves it.
  • Site wide management of plugins and themes: Bedrock disables this kind of functionality through wp-admin anyway, so no benefit here.

Other benefits of multisite that I can think of:

  • Single deployments: with a multiple sites configuration I have to deploy to each site separately, which adds a considerable amount of time.

After experimenting with multisites for a day, I gave up and reverted to a multiple sites configuration. I might try multisite again someday. I imagine the single deployments would be a big time saver in some cases. The only other big problem I can see with multisite would be figuring out a good development / syncing strategy.

I do a sort of pseudo multisite for a network of sites I run. I have a client with about 15 sites that all run the same codebase but have different data and users.

They all share the same codebase and servers and web root and are deployed with one deployment. Instead of one .env file though, I have a different .env file for each site and have some code that loads a different .env file based on which site.

I had to customize trellis as well to do this.

Thanks for sharing. That sounds like an efficient set up. Do the sites all share a single uploads folder as well? I’m not sure I’m ready for heavy trellis customisation but I might consider something like this in future.

No, I have this filter in mu-plugins:

add_filter( 'upload_dir', function( $uploads ) {
	// append the constant SITEKEY to the uploads directory
	$uploads_path = 'uploads/' . SITEKEY;
	$basedir = WP_CONTENT_DIR . '/' . $uploads_path;
	$baseurl = WP_CONTENT_URL . '/' . $uploads_path;
	$subdir = $uploads['subdir'];
	$uploads['basedir'] = $basedir;
	$uploads['baseurl'] = $baseurl;
	$uploads['path'] = $basedir . $subdir;
	$uploads['url'] = $baseurl . $subdir;
	return $uploads;
} );

Where SITEKEY is a site specific key I set via the .env file.

1 Like

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