Dotenv ​

Forme uses a dotenv file in which you can set environment variables.

This should be called either forme.env or .env and placed in FORME_PRIVATE_ROOT, i.e. wherever your vendor folder lives.

If both of them exist, forme will use forme.env

# forme.env
MY_API_TOKEN="1d7f8d2e-f744-4321-bec2-9c05e67d4978"
MY_ENV_VAR="FooBar"

Why dotenv? ​

You should never store sensitive credentials in your code. Anything that is likely to change between deployment environments – such as database credentials or credentials for 3rd party services – should be extracted from the code into environment variables. The forme.env file should never go into version control since it can contain sensitive API keys and passwords.

Scope and dotenv example files ​

Our global forme.env covers the whole installation. Plugins and themes can have their own individual forme.env.example which should go into version control. This should show a blueprint of which env variables the plugin or theme needs, with placeholders for any sensitive credentails. These should then be manually added to the global forme.env with the actual variables.

Doesn't WordPress already do this in wp-config? ​

Yeah WordPress sets global constants with a similar rationale. The Dotenv pattern is generally considered slightly better practise for values that are likely to change between environments though.

This means database credentials could arguably also move into the dotenv - Bedrock does this, for example. However Forme's philosophy is to leave the default WordPress configuration alone as far as possible. Therefore as far as Forme is concerned, what goes in wp-config by default stays in wp-config.

Retrieving environment variables ​

Use the env helper function.

$myToken = env('MY_API_TOKEN');
$myVar = env('MY_ENV_VAR');