Use one configuration file per environment

Like Bedrock does.
A common configuration file using environment variables or using dotenv allowing to define db passwords and salts.

Special configuration files for each environment :

  • development
  • staging
  • production

Read-only archive:

Author: Alan

Vote count: 31

Status: open


  • request-add-feature


This petition had a decent amount of votes. Quoting what @james wrote back then, this seems to be the approach we would take if this is something the community still wants.

Full integration would require third-party dependency added to the core, similar to PHPMail, I assume. This would also mean the installer would need to write DB details to the .env file, not wp-config.php. This would be touching the 12-factor app approach. But is it the right solution for ClassicPress?

Would a core plugin be a better approach? Or is this not necessary?

1 Like

In my opinion, probably not, the default way of configuring ClassicPress should remain the same. Using a .env file instead is fairly advanced: people who do this generally do it as part of a larger strategy that includes the process of deploying to multiple environments, so some level of knowledge and familiarity with server administration is assumed. However we could indeed bundle the library that reads .env files as a dependency to make this easier to achieve.

Configuration is outside of the scope of plugins because all of the config values need to be loaded and finalized well before any plugin code has executed.

I recall that @mikeschinkel has spent a good bit of time on this problem and came up with a solution that uses arrays for configuration, with the ability to cleanly specify different values for different environments. Even though I personally will continue using .env files, I think an approach like this is probably a better candidate for inclusion into core, and I’d be open to revisiting this work and coming up with an actionable plan to include it or something similar in ClassicPress.

In the meantime, another, simpler approach that I have used successfully is as follows:

  • In wp-config.php, define all the values that do not change between different environments of the site, and require a file named wp-config-local.php.
  • Put the values that really need to differ between environments, such as database connection information, into wp-config-local.php. Maintain a separate version of this file for each environment - it should be very short and simple.
  • In the version control for the site, commit and deploy the wp-config.php file, and ignore the wp-config-local.php file.

Do you think we should include a custom solution and create documentation to teach developers how to use it? I think sticking with the industry’s best practice of using .env for configs would be more beneficial, developers are already familiar with using .env.

We’ve used .env in our internal Python projects, and I like how it works. I think sticking with modern practices, like using GitHub, will help bring in more developers.


.env files are not natural to people that have only a passing understanding in administrating a server, especially since the concept is all about controlling features via OS enviroment variables.

Having to manage part of the configuration via PHP defines and another part via ini style sytax seems to be pointless if the ini style do not add any obvious benefits.

The fact that wp-config.php is an actual code and not an ini style file sucks, and hopefully no one would have built a configuration file this way today, but you can not fight 15 years of inertia here.

In calm I went with a similar scheme to what james suggests


Based on the discussion, I don’t think we’ll be changing how configuration file works in CP. It might be good to recommend a solution in documentation for those that may need it.

1 Like

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