This is How WordPress Multisite and Single Database Can Benefit All Developers
Introduction
Ok, let me take you on a journey. Your centralized dev environment sounds very unique, but I think we can work with that. In this article, we'll explore how to set up a WordPress multisite with a single database that works seamlessly across your local, staging, and live environments.
We'll cover:
- Consistent Configuration Across Environments: How to ensure your wp-config.php settings are consistent across local, staging, and live sites.
- Handling Multisite Domains: Techniques for managing domain names and URLs in a multisite setup.
- Streamlining Database Management: Leveraging a single database to power all your sites, even with different domain names.
- Enhancing Developer Productivity: How this approach can simplify your development workflow and improve collaboration.
By the end of this article, you'll have a solid understanding of how to implement a WordPress multisite with a centralized database, making your development process more efficient and reliable.
Consistent Configuration Across Environments
Let's start by ensuring your wp-config.php settings are consistent across your local, staging, and live environments. This is crucial for maintaining a seamless development workflow.
First, let's define the standard multisite settings in your wp-config.php:
define( 'WP_ALLOW_MULTISITE', true );
define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false );
define( 'DOMAIN_CURRENT_SITE', 'example.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );
Notice that DOMAIN_CURRENT_SITE
is set to the live domain, example.com
. This is important, as we'll need to handle the different domain names used in each environment.
Next, let's add some additional settings to your wp-config.php, but only in your local and staging configurations (not the live config):
/** Set this to your local tld setup */
define( 'WP_HOME', 'http://example.local' );
define( 'WP_SITEURL', 'http://example.local' );
/** Include wp-content/sunrise.php */
define( 'SUNRISE', true );
/** This should be the TLD in the database */
define( 'WP_PROD_TLD', '.com' );
/** This should be the tld of your local copy */
define( 'WP_DEV_TLD', '.local' );
These settings allow us to handle the different domain names used in each environment, as we'll see in the next section.
Handling Multisite Domains
To ensure your multisite setup works seamlessly across local, staging, and live environments, you'll need to manage the domain names used in each environment. We'll do this by leveraging a custom sunrise.php
file.
Here's an example sunrise.php
file:
<?php
/**
* File sunrise.php
*
* This allows us to copy the production multisite database to staging/dev and still use
* it directly without altering domains
*/
/**
* Filter /wp-includes/ms-load.php get_site_by_path to find production domains
**/
function dev_get_site_by_path($_site, $_domain, $_path, $_segments, $_paths) {
global $wpdb, $path;
// Get our actual domain in the database (should be set to production domain)
// The domain coming in should be the request domain
$domain = str_replace( WP_DEV_TLD, WP_PROD_TLD, $_domain);
// Search for a site matching the domain and first path segment
$site = $wpdb->get_row( $wpdb->prepare( "SELECT * FROM $wpdb->blogs WHERE domain = %s and path = %s", $domain, $_paths[0] ) );
$current_path = $_paths[0];
if ($site === null) {
// Specifically for the main blog - if a site is not found then load the main blog
$site = $wpdb->get_row( $wpdb->prepare( "SELECT * FROM $wpdb->blogs WHERE domain = %s and path = %s", $domain, '/' ) );
$current_path = '/';
}
// Set path to match the first segment
$path = $current_path;
return $site;
}
add_filter('pre_get_site_by_path', 'dev_get_site_by_path', 1, 5);
add_filter('pre_get_network_by_path', 'dev_get_site_by_path', 1, 5);
/**
* Filter the site_url and home options for each site, and
* filter /wp-includes/link-template.php::network_site_url()
* and /wp-includes/link-template.php::network_home_url()
* so that our network site link is correct in the admin menu
*/
function dev_network_url( $_url = '' ) {
return str_replace( WP_PROD_TLD, WP_DEV_TLD, $_url );
}
add_filter( 'network_site_url', 'dev_network_url' );
add_filter( 'network_home_url', 'dev_network_url' );
add_filter( 'option_siteurl', 'dev_network_url' );
add_filter( 'option_home', 'dev_network_url' );
This sunrise.php
file is only included via wp-config.php on your local and staging environments, never on the live server. It filters the request to get a network "site by path", which means it looks at the domain and path requested from the client, and matches the domain and path in the wp_blogs
table.
The key is that we're checking the domain for our live TLD (in this case, .com
) and replacing it with the TLD of the current environment (our local copies are .local
, the staging server is .staging.com
). We're also filtering the WP_HOME
and WP_SITEURL
options per site at the bottom.
With this setup, your live domains in the database are being translated on the fly for your local and staging site environments. As long as you're using subfolders or you have aliases set up in your local vhost settings, this should work seamlessly.
Streamlining Database Management
One of the main benefits of this approach is the ability to use a single database to power all your sites, even with different domain names. This simplifies your database management and makes it easier to keep your environments in sync.
Here's how it works:
- Local and Staging Environments: Your local and staging environments will use the same database as your live site, but the domain names will be translated using the
sunrise.php
file.
- Live Environment: Your live site will use the same database, without any need for domain name translation or additional configuration.
This means you can easily copy your production database to your local and staging environments, and everything will just work. You don't have to worry about maintaining separate databases or manually updating domain names in the database.
Enhancing Developer Productivity
This approach to WordPress multisite and single database management can greatly enhance your development productivity in several ways:
-
Consistent Environments: By using the same database and consistent configuration across all environments, you can ensure that your local, staging, and live sites behave the same way, reducing the risk of unexpected issues during deployment.
-
Easier Collaboration: When all developers are working against the same database, it becomes easier to collaborate on content, settings, and theme/plugin development. You can easily share data and test changes across the team.
-
Simplified Deployment: With a single database powering all environments, deploying updates to your live site is as simple as a Git pull on the server. No need for complex database migration scripts or manual interventions.
-
Reduced Maintenance: Managing a single database for all your sites is much more efficient than maintaining separate databases for each environment. This saves time and reduces the risk of errors.
By implementing this WordPress multisite and single database setup, you can streamline your development workflow, improve collaboration, and focus more on building great features for your users.
Get a Free AI Website Audit
Automatically identify UX and content issues affecting your conversion rates with Flowpoint's comprehensive AI-driven website audit.
Conclusion
In this article, we've explored how to set up a WordPress multisite with a single database that works seamlessly across your local, staging, and live environments. By leveraging consistent configuration, domain name management, and a centralized database, you can improve your development productivity, reduce maintenance overhead, and deliver a more reliable product to your users.
If you're interested in learning more about how Flowpoint.ai can help you identify and fix technical issues that impact your website's conversion rates, be sure to check out our website