Update configuration.rst to avoid misunderstanding #16394
Conversation
There was a problem hiding this comment.
perhaps target v5.4?
Even more, you can also reword the next paragraph and instead of using composer dump-env, use the new same symfony feature symfony/symfony#42610 :)
mertingen
changed the title
|
@94noni Thanks for referring to it. Should I change the base branch from 6.0 to 5.4? In addition to that, how does that command work? Should I change the following? From To Or |
We shouldn't deploy the ".env.local" file for the production environment variables. We just need to add the ".env" file into Git and manually create a new ".env.local" file on the production machine. In the old expression says, "deploying" and it might be a misunderstanding in this way. I changed it to "creating". Old expression: In production, the ``.env`` files are also parsed and loaded on each request. So the easiest way to define env vars is by deploying a ``.env.local`` file to your production server(s) with your production values.
|
Thanks @mertingen! I've merged this in 4.4, the oldest branch that we still maintain (and this change applies to). We're not sure how to document the new And to answer your question: |
We shouldn't deploy the ".env.local" file for the production environment variables. We just need to add the ".env" file into Git and manually create a new ".env.local" file on the production machine. In the old expression says, "deploying" and it might be a misunderstanding in this way. I changed it to "creating".
Old expression:
In production, the
.envfiles are also parsed and loaded on each request. Sothe easiest way to define env vars is by deploying a
.env.localfile to yourproduction server(s) with your production values.