Fork me on GitHub

System environment variables at Seravo

In all Seravo’s environments (production, staging/testing shadow, local development etc) there are many environment variables defined. Examples include:

WP_ENV

The environment variable WP_ENV always contains the environment name. When code is running on the live production site it always sees a WP_ENV with the value production. Different testing environments have different names, e.g. staging and development.

CONTAINER

This is the name of a particular environment instance. For example example_1ab2c3. This may change over time. Don’t write any logic in your WordPress code based on this.

DEFAULT_DOMAIN

This is the internal domain name given to a live production site given by Seravo. An example could be example.fi.seravo.com. It is used in cases when the real external domain (e.g. example.com) has not yet been registered, does not point to the site or might have some other issue and does not work.

REDIS_HOST and REDIS_PORT

These always contain the Redis server address and port.

DB_HOST, DB_NAME, DB_USER, DB_PASSWORD

These always contain the database credentials. Please rely on these and the database connection will always work even when you have different passwords in production and in testing. Avoid from hardcoding any passwords or server addresses in your code.

AUTH_KEY, LOGGED_IN_, NONCE_, SECURE_AUTH_*

Each of these contain a unique key (e.g. xifablhk84nimz4k6p71b5b2hvuq0js66m9db7vcfthdxa4bvtumfykirwfq342q) which is different from environment to environment, but always the same inside the same environment. Using these constants makes the source code of your WordPress site more secure, since it will be void of any secrets. Below is an example of how the wp-config.php at any site at Seravo looks like:

/**
 * Authentication Unique Keys and Salts
 * You can find them by running $ wp-list-env
 */
define('AUTH_KEY',         getenv('AUTH_KEY'));
define('SECURE_AUTH_KEY',  getenv('SECURE_AUTH_KEY'));
define('LOGGED_IN_KEY',    getenv('LOGGED_IN_KEY'));
define('NONCE_KEY',        getenv('NONCE_KEY'));
define('AUTH_SALT',        getenv('AUTH_SALT'));
define('SECURE_AUTH_SALT', getenv('SECURE_AUTH_SALT'));
define('LOGGED_IN_SALT',   getenv('LOGGED_IN_SALT'));
define('NONCE_SALT',       getenv('NONCE_SALT'));

Using Dotenv

The wp-config.php file uses Dotenv by default which enables you to create a file called .env in the root of your project to override default environment variables.

Example:

$ cat .env.development
# Run 'ln -s .env.development .env' in project root to activate this
WP_TEST_URL=https://example.dev
DOMAIN_CURRENT_SITE=example.dev
NOBLOGREDIRECT=https://example.dev
COOKIE_DOMAIN=.example.dev

$ ll .env
lrwxrwxrwx 1 otto otto .env -> .env.development

You can have template files like .env.development tracked in version control, and then make a location-specific symbolic link from .env to the correct file. By default the .env file is and should be ignored by git via gitignore.

Note on Dotenv version 2.4.0

In the version 2.4.0 the syntax of Dotenv changed. In new instances of wp-config.php you will find lines like:

$dotenv = new Dotenv\Dotenv($root_dir);
$dotenv->overload();

The older syntax was:

Dotenv::makeMutable();
Dotenv::load($root_dir);

The version of Dotenv on your site (and syntax in your wp-config.php) is what was at the time when the site was created. If you later run composer update and thus update Dotenv to version > 2.4.0, you need to update the lines in your wp-config.php manually, otherwise your WordPress will just display a blank page and your /data/log/php-error.log will have fatal error messages about Dotenv.