#473 Add feature to load server environment variables from special file by MartinPeverelli · Pull Request #474 · laravel/valet

MartinPeverelli · 2017-11-24T20:36:55Z

Proposal for #473

Closes #473
Closes #146

Lloople · 2018-02-13T11:16:22Z

Hi @adamwathan @mattstauffer, is there any reason for not merge this pull request? I found that I need to set env variables per site and can't find a proper way. Adding this .env.valet file into the project looks pretty neat.

Thank you

EDIT: I'm talking about not-laravel projects

mattstauffer · 2018-02-14T03:26:39Z

@Lloople I don't see anything particularly wrong with the PR. What I did was close obvious "no" PRs, shut down all driver requests for now, and leave PR's like these open for Adam and Taylor to merge when they have some time to look over them and decide whether they fit within the spirit/intent of Valet. I think this being open is not a "no" but just a "taylor and adam haven't had time to dig into it yet".

iboldurev · 2018-03-06T14:19:47Z

Please add this implementing

osrecio · 2018-06-05T12:39:02Z

Hi, I think is a good approach for some kind of projects to have env variables and load it inside a project.

Totally agree to merge it @mattstauffer

bramus · 2018-07-06T10:30:50Z

Nice work! Would love to see this one get merged.

drbyte · 2018-09-18T21:21:38Z

Notwithstanding the merge conflict here (which I think is a simple fix), and that this PR touches most drivers, I like this.
I think it provides an easy-to-use-and-understand way of providing ENV variables on a per-project basis, beneficial specifically to those using Valet.

One concern: naming the file .env.valet could be confusing since .env files are typically expected to contain settings in a prescribed VAR=setting format, but this PR expects the file to be a PHP file containing an array declaration.
Thus I propose calling it .valet-config.php or maybe .valet-env.php

mattstauffer · 2018-09-19T04:09:21Z

     */
    public function frontControllerPath($sitePath, $siteName, $uri)
    {
+        $this->loadServerEnvironmentVariables($sitePath, $siteName);


Since this seems to be happening in every frontControllerPath method, is it possible to instead just run this in server.php right before it calls frontControllerPath? (I don't know the code super well so there may be a good reason why not...)

Technically it probably could.

valet/server.php

Lines 134 to 147 in 0323607

/**

* Attempt to dispatch to a front controller.

*/

$frontControllerPath = $valetDriver->frontControllerPath(

$valetSitePath, $siteName, $uri

);

if (! $frontControllerPath) {

show_valet_404();

}

chdir(dirname($frontControllerPath));

require $frontControllerPath;

…cial file

MartinPeverelli · 2018-09-24T19:08:58Z

@mattstauffer @drbyte I took both your advices and refactored this idea.
The file is now .valet-env.php, which makes it obvious that it should contain a PHP array (instead of the key=value pairs of regular dotfiles).
And I changed the method to be public and called it from server.php as requested, which allowed me to revert all the changes to all the Drivers.

Let me know what you think!

If this gets merged into master, I would also love to help with the documentation of this feature, how can I do that?

Lloople · 2018-09-26T10:54:38Z

+        }
+
+        foreach ($variables[$siteName] as $key => $value) {
+            $_SERVER[$key] = $value;


Why not using putenv($key.'='.$value) here along with the already existing $_SERVER? 🤔

I was only trying to mimic Apache's way of loading env vars on the vhosts files, and if I'm not mistaken, that only sets values on$_SERVER.
I don't know if duplicating the values on both $_SERVER and $_ENV is useful or desirable, but as you say, we can add that single line to the loop if we do.

What say the rest of us?

I have no objection.

drbyte · 2018-09-27T15:36:45Z

@MartinPeverelli have you considered a way to allow for wildcard domain-names with this?

I have a use-case where simply dropping in a non-domain-specific .valet-env.php file would make environment overrides easier. But I don't want to have to edit the file to set domain name/s inside it.
It's admittedly a little different use-case than your original need which was to do domain-specific custom overrides.

drbyte · 2018-11-07T15:07:47Z

I've used this proposed PR on a project. It worked well.

I do think altering it to allow for being domain-agnostic would be nice too.

- added `putenv()` for Laravel compatibility - added `$_ENV` for generic compatibility - added wildcard processing, so site array named `*` gets processed always (if present), and then site-specific entries are added and will override the wildcard. Sample `.valet-env.php`: ```php <?php return [ '*' => [ 'USER' => 'vagrant', ], 'demo' => [ 'MY_CUSTOM_VAR' => 'special_value', 'USER' => 'travis', ], ]; ``` (Note: order of entries in the array is irrelevant, as the parser reads `*` first, followed by site-specific entries.)

drbyte · 2018-12-28T16:19:34Z

Waiting for @MartinPeverelli to merge my PR to his valet fork, which will update this PR, and then this could be merged.

Updated loading of server environment variables

MartinPeverelli · 2018-12-28T17:08:58Z

@drbyte merged your PR into my fork! Sorry for the delay, hectic RL.

drbyte · 2018-12-28T17:47:57Z

Thanks @MartinPeverelli

I've been using this code for the past 3 weeks, and haven't run into any problems. It's definitely been helpful to keep project-specific environment variable configs in a separate .valet-env.php file in my app, instead of having to touch the valet-generated nginx configs.

@mattstauffer IMO this is safe to merge.

mattstauffer · 2019-01-02T22:26:58Z

Should we possibly add a PR to the docs while we're at it?

mattstauffer · 2019-01-16T21:17:59Z

I think I got mixed up and thought this was adding .env.valet to each application, not env-valet.php to the root. Is there a reason we went this way? I was about to release but this feels weird.

MartinPeverelli · 2019-01-16T21:23:23Z

The change to the file name was because the contents are a PHP array, instead of the key=value pair on the other .env files.

mattstauffer · 2019-01-16T21:31:27Z

@MartinPeverelli sure... and you had to do PHP so you can differentiate them per domain. I remember now. Thanks!

drbyte · 2019-01-16T21:31:39Z

Note: The filename is .valet-env.php

mattstauffer mentioned this pull request Jan 4, 2018

Idea: Valet environment variables #146

Closed

MartinPeverelli mentioned this pull request Jun 3, 2018

Allow to have an stores.json file in the project to easily setup multiple storeviews weprovide/valet-plus#182

Closed

mattstauffer reviewed Sep 19, 2018

View reviewed changes

laravel#473 Add feature to load server environment variables from spe…

a603114

…cial file

MartinPeverelli force-pushed the server_environment_variables branch from fea72f9 to a603114 Compare September 24, 2018 19:04

Lloople reviewed Sep 26, 2018

View reviewed changes

drbyte mentioned this pull request Dec 8, 2018

Adding PHP Server Environment Variable (from computer paths) #682

Closed

Merge pull request #1 from drbyte/patch-1

8973ec2

Updated loading of server environment variables

mattstauffer merged commit 67546f1 into laravel:master Jan 2, 2019

drbyte mentioned this pull request Jan 6, 2019

Shell script does not use the same environment as the terminal shell #585

Closed

mattstauffer mentioned this pull request Jan 29, 2019

New features need documentation #719

Closed

4 tasks

ahinkle mentioned this pull request Mar 5, 2019

[5.8] Valet Site Specific Environment Variables laravel/docs#5038

Merged

anugupta mentioned this pull request Jul 24, 2023

[Feature Request]: Support .valet-env.php beyondcode/herd-community#43

Closed

	/**
	* Attempt to dispatch to a front controller.
	*/
	$frontControllerPath = $valetDriver->frontControllerPath(
	$valetSitePath, $siteName, $uri
	);

	if (! $frontControllerPath) {
	show_valet_404();
	}

	chdir(dirname($frontControllerPath));

	require $frontControllerPath;

Uh oh!

Conversation

MartinPeverelli commented Nov 24, 2017 • edited by mattstauffer Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Lloople commented Feb 13, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mattstauffer commented Feb 14, 2018

Uh oh!

iboldurev commented Mar 6, 2018

Uh oh!

osrecio commented Jun 5, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bramus commented Jul 6, 2018

Uh oh!

drbyte commented Sep 18, 2018

Uh oh!

mattstauffer Sep 19, 2018

Choose a reason for hiding this comment

Uh oh!

drbyte Sep 19, 2018

Choose a reason for hiding this comment

Uh oh!

MartinPeverelli commented Sep 24, 2018

Uh oh!

Lloople Sep 26, 2018

Choose a reason for hiding this comment

Uh oh!

MartinPeverelli Sep 26, 2018

Choose a reason for hiding this comment

Uh oh!

drbyte Sep 27, 2018

Choose a reason for hiding this comment

Uh oh!

drbyte commented Sep 27, 2018

Uh oh!

drbyte commented Nov 7, 2018

Uh oh!

drbyte commented Dec 28, 2018

Uh oh!

MartinPeverelli commented Dec 28, 2018

Uh oh!

drbyte commented Dec 28, 2018

Uh oh!

mattstauffer commented Jan 2, 2019

Uh oh!

mattstauffer commented Jan 16, 2019

Uh oh!

MartinPeverelli commented Jan 16, 2019

Uh oh!

mattstauffer commented Jan 16, 2019

Uh oh!

drbyte commented Jan 16, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

MartinPeverelli commented Nov 24, 2017 •

edited by mattstauffer

Loading

Lloople commented Feb 13, 2018 •

edited

Loading

osrecio commented Jun 5, 2018 •

edited

Loading