You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I don't necessarily dislike the idea, but I think this might be outside of the scope of WP-CLI.
Why are your environment variables not part of your normal WP bootstrap, if they are needed? Is there a specific reason why this type of setup couldn't just be part of your actual project, instead of coded into WP-CLI?
Trying to discuss through this to find out whether we're actually improving something here...
So you have your environment variables as real environment variables on your server, not inside of a .env file. That is generally how you should set up a production server, whereas you'd be fine with a .env file on development machines. All fine here if the servers you are referring to are production machines and you access them over SSH.
However, what you have proposed above to add an env: section to wp-cli.yml would have the same security drawbacks than a regular .env file, only that is then specifically tied to a WP-CLI implementation, instead of the more standard .env file convention.
The only way to avoid reintroducing the drawback of a .env with such a config change would be to have the env: section in your global user config ~/.wp-cli.yml under aliases. However, that means that you have all sorts of project internals for all of your sites inside of one global config. Are you sure that would improve your situation?
I generally discourage developers to use .env for WordPress. Using real environment variables is OK.
In your scenario, I don't see why having environment variables in ~/website/wp-cli.yml would be any better than having them in ~/website/.env, though. The only difference I can see is that the latter is a standard convention.
I'll leave this issue open here for now, and maybe mention it during office hours, to see whether other folks might have insights to share.
Then it makes sense to have DOCKER_HOST set within .wp-cli/config.yml instead of doing: DOCKER_HOST=ssh://test-server wp @remote-wp core version
It's also less error-prone (eg: if the same container name exists locally): the container name and the host serving it are configured in the same file.
Activity
schlessera commentedon Oct 24, 2018
I don't necessarily dislike the idea, but I think this might be outside of the scope of WP-CLI.
Why are your environment variables not part of your normal WP bootstrap, if they are needed? Is there a specific reason why this type of setup couldn't just be part of your actual project, instead of coded into WP-CLI?
szepeviktor commentedon Oct 24, 2018
We use a skeleton (without actual values) wp-config with 20+ env-s.
Something like https://m.dotdev.co/secure-your-wordpress-config-with-dotenv-d939fcb06e24
In PHP-FPM envs are in the pool config file. When running on CLI I need a WP-CLi-integrated solution to set envs.
So an
env:section would be great.szepeviktor commentedon Oct 24, 2018
BTW The DotEnv project is for development only, for example Laravel caches its values in a plain PHP file.
schlessera commentedon Oct 24, 2018
Trying to discuss through this to find out whether we're actually improving something here...
So you have your environment variables as real environment variables on your server, not inside of a
.envfile. That is generally how you should set up a production server, whereas you'd be fine with a.envfile on development machines. All fine here if the servers you are referring to are production machines and you access them over SSH.However, what you have proposed above to add an
env:section towp-cli.ymlwould have the same security drawbacks than a regular.envfile, only that is then specifically tied to a WP-CLI implementation, instead of the more standard.envfile convention.The only way to avoid reintroducing the drawback of a
.envwith such a config change would be to have theenv:section in your global user config~/.wp-cli.ymlunder aliases. However, that means that you have all sorts of project internals for all of your sites inside of one global config. Are you sure that would improve your situation?szepeviktor commentedon Oct 24, 2018
You know it seems much simpler to me.
~/website/wp-cli-envs.phpfile (also a file)~/website/wp-cli.ymlresulting in one less file (also a file)I generally discourage developers to use .env for WordPress. Using real environment variables is OK.
ps. my policy is to have one Linux user with a /home/ directory for each website - usually 1 website per server
ps2 document root is
~/website/code/so wp-cli.yml lives above itschlessera commentedon Oct 24, 2018
In your scenario, I don't see why having environment variables in
~/website/wp-cli.ymlwould be any better than having them in~/website/.env, though. The only difference I can see is that the latter is a standard convention.I'll leave this issue open here for now, and maybe mention it during office hours, to see whether other folks might have insights to share.
szepeviktor commentedon Oct 24, 2018
It could be a misunderstanding. In my case there is no such option!
https://github.com/vlucas/phpdotenv says:
so I do not allow it nor in PHP-FPM nor in CLI.
It is a wp-cli-envs.php vs. wp-cli.yml decision, not a wp-cli.yml vs. .env one.
drzraf commentedon Aug 20, 2024
I've a valid use-case for this: environment variables related to wp-cli connection settings, namely ssh/docker.
Assuming
my-test-containeris hosted ontest-server(available via ssh):Then it makes sense to have
DOCKER_HOSTset within.wp-cli/config.ymlinstead of doing:DOCKER_HOST=ssh://test-server wp @remote-wp core versionIt's also less error-prone (eg: if the same container name exists locally): the container name and the host serving it are configured in the same file.