Go to content
WordPress, like many CMSs, only has support out-of-the-box for one environment which makes testing difficult. There are various solutions to this, and at Studio 24 we've developed a simple configuration system that makes managing multiple environments in WordPress really easy.

At Studio 24, it’s standard practise to have a local development environment, a test staging website and live production website for client projects. This enables us to develop the site locally, test it with the client and then go live. It’s important to have this separation in order to safely make changes and test these without having to make things live immediately. This concept of developing a site in multiple environments is pretty standard best practise, but one that CMS tools rarely support.

In practise for WordPress this means different configuration (i.e. database connection details) and critically a different testing URL. The custom URL is a pain in WordPress since this is set in the database and the whole website auto-redirects if you’re not accessing it via the correct live URL. Good for security no doubt, but a pain for web development.

Another CMS we use a lot, ExpressionEngine, has a good solution from the fine folks at Focus Labs who created the EE Master Config. This solution used a different config file per enviroment which I really like from the point of view of easy maintenance.

So we developed a simple solution for WordPress that supports one config file per environment. We also built in support for a default config file, which allows us to set defaults such as authentication unique keys.

You can download our WordPress multi-environment config from GitHub. The setup is pretty straightforward and is detailed in the README file. I’ll briefly explain how it works below.

The multi-environment config system basically replaces your wp-config.php file with one that conditionally loads the correct config file based on your current environment. This can be set in one of two ways: either via the current hostname (you define these in wp-config.env.php); or via the WP_ENV environment variable (which you can set, for example, in your Apache vhost).

Once the environment has been detected it sets the WP_ENV constant with the current environment name, for example “development”.

The system then loads the default config file wp-config.default.php, which should contain any common configuration settings you have which are the same across all environments. Common examples of these are the authentication unique keys and salts or database table prefix.

Next, the system loads the environment-specific config file. This is named wp-config.{environment}.php, so if your local environment is called “development” the appropriate config file is called wp-config.development.php. This file usually contains things like database credentials and error reporting. You can override settings from the default config file, as long as they’re not constants. Once defined, you can’t override a constant in PHP.

Finally, the system sets the WordPress constants WP_SITEURL and WP_HOME which define the URL of your WordPress site. This means WordPress will work fine in different environments without you needing to hack the database to update your site URLs. Please note this overrides the site URL options in your database that are set via the WordPress Address and Site Address fields on the WordPress Settings page.

Full installation instructions are on GitHub at github.com/studio24/wordpress-multi-env-config, if you have any issues or suggestions for improvements please let me know.

There are still other issues with developing with multiple environments, like how to migrate database data between environments, but this solution gives you a clean way to manage different configs across different environments.

It is surprising that so few CMSs support multiple environments out-of-the box given how many people develop this way. Perhaps with the current active development on WordPress, this may change sometime in the future!