Technology

Creating Better WordPress Environments with dotenv

If you’re a Laravel developer, you’re intimately familiar with the .env configuration file. It seems so obvious, and you probably wonder how you ever lived without it. And, if you develop in WordPress as well, you’re constantly reminded WordPress doesn’t ship with such a feature.

If you’re a WordPress developer that works in multiple environments (development, staging, production) and have no idea what we’re talking about...read on.

A .env file is a specific configuration file that supports a particular environment. It allows you to easily store environment specific information without publicly sharing it in the wp-config.php file. That way you can keep environment-specific database settings, domain-specific API keys, caching directives, and pretty much anything you want to be used on your local development instance. The file doesn’t get committed to the repository, and it doesn’t get shared with other developers. Each developer would run the site locally with their own .env file. The same goes for staging and production environments. It’s a wonderfully simple and useful concept.

There are a few ways to get started. We’ll go over the way we do it using Composer. If you are not using Composer in your project, take a look at a different version that uses an npm package to achieve the same results. Here is a good tutorial using the npm package. For an existing project utilizing Composer, you’ll simply pull in the Composer package.

composer require vlucas/phpdotenv

Then you’ll create a new file in your project root and name it .env. In that file, paste the following text and update the values to match your local environment’s database credentials.

ENVIRONMENT=dev

DB_NAME=database_name
DB_USER=database_user
DB_PASSWORD=database_password
DB_HOST=127.0.0.1
DB_PREFIX=wp_
DB_SAVE_QUERIES=0
WP_AUTO_UPDATE_CORE=1
WP_DEBUG=0

Next, you’ll need to edit your wp-config.php file. You’ll need to add this to the top of the file.

require_once realpath(__DIR__.'/../vendor/autoload.php');
(new \Dotenv\Dotenv(__DIR__.'/../'))->load();
define('ENVIRONMENT_DEV', 'dev');
define('ENVIRONMENT_STAGE', 'stage');
define('ENVIRONMENT_PROD', 'prod');
define('ENVIRONMENT', getenv('ENVIRONMENT'));

/** no errors on production **/
if (ENVIRONMENT === ENVIRONMENT_PROD) {
    error_reporting(0);
    @ini_set('display_errors', 0);
}

Then you’ll want to update the following lines to use the values in the .env file.

define('DB_USER', getenv('DB_USER'));

define('DB_PASSWORD', getenv('DB_PASSWORD'));

define('DB_HOST', getenv('DB_HOST'));

define('DB_NAME', getenv('DB_NAME'));

define('SAVEQUERIES', (bool) getenv('DB_SAVE_QUERIES'));

$table_prefix  = getenv('DB_PREFIX');

define('WP_DEBUG', (bool) getenv('WP_DEBUG'));

define('WP_AUTO_UPDATE_CORE', (bool) getenv('WP_AUTO_UPDATE_CORE'));

Now the last step you’ll need to do within your development environment is to add the .env file to your .gitignore file so it doesn’t get committed to your repository.

To get it working on your other environments, you’ll simply create a copy of your local .env file and update the values to match the current environment.