I was recently playing around with WordPress Multisite and was surprised to find that a good guide to installing WordPress multisite did not exist for the Roots stack, including Bedrock and Sage 10. While you can install WordPress Multisite very similarly to how you would with standard WordPress, there are some minor differences that can cause some weird and broken behavior on your Multisite network, so this guide will address how to fix this behavior and get your Multisite running with Bedrock and Sage 10.
Before you can enable WordPress Multisite, you’ll need to have a standalone WordPress site installed to where you can get to the Dashboard. You’ll also want to enable pretty permalinks inside of your dashboard. I prefer the format where each post has its own name in the URL but you can also set this up so posts are sorted by date. Once you have WordPress in this state, you can begin the setup required for WordPress Multisite.
The first step is to disable all of your site’s plugins. Multisite won’t let you continue with the installation if plugins are active.
Next, you will want to edit your application.php file (located inside of the “config” folder) and add the following code below the entries for the Debugging Settings section:
Config::define('WP_ALLOW_MULTISITE', true);
This will put WordPress into a state where you can install the Multisite Network. After adding this code, you should be able to go to Tools > Network Setup inside of your WordPress dashboard and start setup of the network. I would recommend using the subdomains option when choosing what type of URLs to use for hosted websites.
Next, WordPress will give you some code to use inside of your config.php file as well as inside of your .htaccess file. The code for the .htaccess file should be placed inside of a .htaccess file inside of your “web” directory. You may need to force add your .htaccess file to source control as by default .htaccess files are ignored by .gitignore. The .htaccess file should work on Apache and LiteSpeed web servers but you may need to make additional server-level changes if you’re using NGINX as your web server.
The changes to config.php should instead be made to your application.php file. Instead of using the changes provided by WordPress, use the following:
Config::define( 'WP_ALLOW_MULTISITE', true );
Config::define( 'MULTISITE', true );
Config::define( 'SUBDOMAIN_INSTALL', true );
Config::define( 'DOMAIN_CURRENT_SITE', $_SERVER['HTTP_HOST']);
Config::define( 'PATH_CURRENT_SITE', '/' );
Config::define( 'SITE_ID_CURRENT_SITE', 1 );
Config::define( 'BLOG_ID_CURRENT_SITE', 1 );
This code assumes that you chose the subdomains option when installing Multisite. I haven’t tested using subdirectories with Bedrock and Sage, but if you chose subdirectories your code will need to be different.
Inside of application.php you will also want to find the following code:
Config::define('WP_HOME', env('WP_HOME'));
Config::define('WP_SITEURL', env('WP_SITEURL'));
Replace that with the following:
Config::define( 'WP_HOME', 'https://' . $_SERVER['HTTP_HOST']);
Config::define( 'WP_SITEURL', 'https://' . $_SERVER['HTTP_HOST']);
Because by default Bedrock and Sage use your .env file to determine your site’s domain, we need to allow the site’s domain to be dynamically assignable based on the URL that users use to view a particular site on your Multisite network. These config values also help to alleviate CORS errors on hosted sites where CSS and JS assets load from the primary domain by default, so these changes instead allow assets to load from the proper subdomain for each hosted site.
Post Installation Troubleshooting
You may now notice that on your primary website in the network all URLs are appended with a /wp suffix. If this happens, check the wp_options table for your primary site and ensure that the domain is correct and doesn’t contain a /wp suffix.
Now that your site is running in Multisite mode, you should access your admin via /wp-admin as the /wp suffix is removed from all site URLs. Roots has a package that claims to fix URLs for sites running in a Multisite configuration but it looks like this package was deprecated when Sage 10 came out. It looks like simply updating the domain and home URL of the primary site in the database fixes any issues with incorrect URLs related to Multisite.
Local Development with WP Multisite
If you want to work with WP Multisite locally, your local development environment should support adding additional subdomains. I use Lando for local WordPress development on Linux. If you’re using Lando, you can use the following .lando.yml file for sites in a Multisite configuration:
name: wp-sage-multi
recipe: wordpress
config:
webroot: web
php: '8.3'
composer_version: '2.7.6'
services:
node:
type: node:20
env_file:
- .env
proxy:
appserver:
- wp-sage-multi.lndo.site
- espanol.wp-sage-multi.lndo.site
In this case, your primary domain would be “wp-sage-multi.lndo.site” and there would be a subdomain of “espanol.wp-sage-multi.lndo.site” that would also be accessible. You should add each additional subdomain on its own line.
If doing local development, you’ll also want to ensure the multisite domains in the database match what you have locally. When transferring a site between live, dev and local you’ll likely have to do a find and replace in your SQL dump to ensure all of your domains are updated.
Need help with WordPress Multisite on Bedrock and Sage 10?
We offer developer mentorship services and can help you configure Sage 10 and Bedrock to work with WordPress Multisite. Schedule a free consultation with us to learn more!