v3: .env.local

[lkraav]

Is your feature request related to a problem? Please describe. I would like to have a committed global app state configuration, and only a subset of local overrides.

Describe the solution you'd like WPStarter processes multiple known dotenv files.

• .env works as is.
• .env.local is also loaded for any overrides (credentials etc).

Describe alternatives you've considered We could maintain a patch queue of local changes to .env, but a bit noisy. We could maintain follow upstream recommendations of only .env.example committed, but then it's more difficult to distribute app-wide change proposals, when everybody's local .env file is a full configuration object, that always has to be manually adjusted.

[gmazzap]

I like the idea. Not sure I like the .env.local approach.

I'll think about it.

Quick alternative ideas:

• .env.override which makes a bit more clear what it does (and similar to what other tools use)
• allow a list of files in env-file config. So one could set { "envfile": ".env, .env.local" } in wp-starter.json and that would tell WP Starter to load all of them in sequence

[lkraav]

env-file array sounds good to me. This moves the freedom and decision burdain down the chain.

[lkraav]

https://github.com/wecodemore/wpstarter/blob/dev/src/Env/WordPressEnvBridge.php is the main change target here, yes?

[gmazzap]

While looking at the code to implement this, I realized this is somehow already possible.

Citing from docs:

After environment variables are loaded [...] WP Starter will look, in the same directory where it looks for "main" env file, [...] for two environment-specific files, i.e. whose name depends on the value of WP_ENV They are:

• an env file named {$envFile}.{$environment}, where $envFile is the name of the "main" env file (by default .env) and $environment is the value of WP_ENV env var;

Which means that to obtain what is described in OP it is possible to:

1. create an .env file that contains, among other variables, WP_ENV=local
2. create and .env.local that contains variables to either add to or overrride variables in .env

Of course, changing the value of WP_ENV will make WP Starter load a different file so that the override will happen according to environment.

However, in the above workflow, the issue is that the environment name is set in the main .env file meaning that there's still the need to have an .env file per-environment.

However, the idea behind this approach is that WP_ENV is not set in files at all, but in the real environment, e.g. in the web server.

If that might be harder might to do in hosted environments, it should be very easy to do locally.

In fact, having:

1. an .env file that does not contain WP_ENV variable
2. a local-only .env.local file 3 .WP_ENV=local set locally in the web server (see docs for Apache and for nginx)

The variables from .env.local will be loaded only locally and will add to or override what's set in .env.

@lkraav Do you think this is enough?

At this point I'm not very keen to support array of env files anymore, exactly for the reason described above. In fact, if I have an array of "base" env files and I need to support environment-based variations of all of them, the loading order starts to become confusing an it is not clear what overrides what.

[lkraav]

Do you think this is enough?

Thanks for the details. I'll do some thinking and experimentation on this tomorrow and report back cc @saas786 @pawelkmpt

[lkraav]

@gmazzap it seems like WP_ENV=local or any other custom value will equate wp-config.php

It turns out https://github.com/wecodemore/wpstarter/commit/8895d8093ad7ee309e92d41f860ba220a0415619 already addresses this concern. Unfortunately commit message didn't mention this issue, or I would've known much earlier.

[lkraav]

Hmm, do you think another beta release could be tagged? It's been a while since beta 2, many useful commits have been added.

I have my requirement nicely sitting at ^3 but it doesn't match the latest master, of course.

$ [git:master+?{1}] composer update wecodemore/wpstarter
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 0 installs, 1 update, 0 removals
  - Updating wecodemore/wpstarter (dev-dev 8b7448f => 3.0.0-beta.2):  Checking out fa870be418

[lkraav]

Also, all composer commands now require WP_ENV=local prefix. Not perhaps the smoothest possible experience.

Wondering whether instructions should be for user to explicitly export WP_ENV=local for each session, or if there's something we can define in composer.json so users wouldn't have to remember this detail.

[lkraav]

Two additional findings:

• .env.local doesn't seem to get loaded for some reason, at least the values in it don't override anything.
• Overrides seem to work perfectly with adding .env.development, so now it seems like .env.local implementation wasn't necessary at all? It looks like I couldn't find / understand the documentation. Unless there's an additional goal for flexibility with ignored .env.local committed .env.development combination.

[gmazzap]

Hmm, do you think another beta release could be tagged?

I guess this is outdated comment. I've tagged a few releases since.

Also, all composer commands now require WP_ENV=local prefix. Not perhaps the smoothest possible experience.

If you export WP_ENV env variables in several wyas... it depends on what you use.

.env.local doesn't seem to get loaded for some reason ... overrides seem to work perfectly with adding .env.development

That's strange. In the code there's nothing treating .env.local in a special way. This code: https://github.com/wecodemore/wpstarter/blob/dev/templates/wp-config.php#L61-L65 should work for local in the same way it does for development.

[lkraav]

$envLoader->loadAppended("{{{ENV_FILE_NAME}}}.{$envType}", WPSTARTER_PATH); does work for incremental upgrades, so I think this issue can be closed.