vars in .env sometimes returns null

[luispastendev]

I don't know why this behavior is caused but sometimes the variables saved in the codeigniter .env file return null

I am trying to test a class and it stopped working because it started to return null, the strange thing is that in other parts of the application I call the variable in the same way and there is no problem

for example:

my class:

   private $refreshSecret;
   public function __construct(Academy $configs){
        $this->refreshSecret = env('jwt.secretRefresh');
   }

my .env file

jwt.secretRefresh = 'super_secret';

When I run my test it fails because the environment variable returns null, I had long ago noticed that error in another project where I used the env ('CI_ENVIRONMENT') which in the same way did not return the configured environment.

I hope someone knows something about this problem :(

[tangix]

I just ran into this problem myself!
CI_ENVIRONMENT from .env is not correct when I do getenv('CI_ENVIRONMENT') in my code.

echo getenv('CI_ENVIRONMENT') = development
var_dump($_ENV)=
/Users/msa/Tangix_Work/sites/verdandi.tangixdev.se/modelmania-api/app/Controllers/Admin.php:94:
array (size=13)
  'BASE_URL' => string 'https://verdandi.tangixdev.se/modelmania-api/public' (length=51)
  'CI_ENVIRONMENT' => string 'production' (length=10)
  'challenge.id' => string 'mm2021.dev' (length=10)
  'challenge.waitingroom' => string '10' (length=2)
  'challenge.regperiod' => string '120' (length=3)
  'challenge.length' => string '25' (length=2)
  'challenge.start' => string '-1' (length=2)

This is on macOS with PHP 7.3.26 and apache installed using homebrew.
Checking phpinfo() from the server I don't see CI_ENVIRONMENT being set so it's not a system-wide configuration.

[tangix]

OK, very scary - I have changed my non-working code from

if (getenv('CI_ENVIRONMENT') === 'development') {
// Do something
}

to

if (getenv('CI_ENVIRONMENT', true) === 'development') {
// Do something
}

The second argument to getenv() is described as Set to true to only return local environment variables (set by the operating system or putenv).
Completely clue-less to as why it has been working before and now suddenly stopped working.
I am using CI 4.0.4.

[luispastendev]

Of course!

I do not know why the problem is due, I experienced it using getenv and it did not work after I used env () and apparently it was solved, now that I am working on another project I used env () and I experienced the null return of a variable, I couldn't see what the problem was and better I wrote a custom configuration file in config /

[tangix]

http://forum.codeigniter.com/thread-78377.html

[paulbalandan]

I think this is not a CI4 thing. According to php.net:

If PHP is running in a SAPI such as Fast CGI, this function will always return the value of an environment variable set by the SAPI, even if putenv() has been used to set a local environment variable of the same name. Use the local_only parameter to return the value of locally-set environment variables.

[paulbalandan]

@luispastendev when you are using env() in your tests, do you mean unit tests using PHPUnit?

[luispastendev]

@paulbalandan Yes! I'm using phpunit, for example right now I run a test taking some configuration variables that I load in my class to use in other methods but when I run my test the variables return null, if I pass the second parameter to env ('foo' , true), it returns true which causes my tests to fail, at the moment I have passed my configuration variables to a php file.

my .env file

[paulbalandan]

@luispastendev if you mean unit testing using PHPUnit when the env variables return null, #4315 now instantiates and loads DotEnv by default in the testing environment. This way env variables will now be uploaded. I experienced this issue recently and saw loading DotEnv is the solution. Since DotEnv is now loaded, this issue is essentially fixed.

[paulbalandan]

Can you try the latest develop to see if you're issue is solved?

[luispastendev]

@paulbalandan That solved the problem in the tests, thank you very much! If I have problems again I will raise a new issue, thank you very much for your time!

[paulbalandan]

Glad we've sorted out this tricky issue. Closing this now.