0

I'm reading some configurables from my .env file. These configurables are used in various places within the project. A few times i've received an exception that one of the env variables does not exist. Example:

ini_set(): It is not safe to rely on the system's timezone settings. You are required to use the date.timezone setting or the date_default_timezone_set() function.

In my .env I have this:

TIMEZONE=Africa/Johannesburg

In the boot function of my AppServiceProvider I have:

ini_set('date.timezone', getenv('TIMEZONE'));

It's as if the .env hasn't loaded at the time im trying to use one of its variables? Ive seen this happen for a few different .env variables at various stages during the application running.

Edit

I am aware of using config for setting the timezone but in this particular instance I must use the .env file as we have a dev-ops team in charge of which servers we point to + we need a support failover that doesn't require a developer's intervention just to point to another server. So I need to know why Laravel seems to have an issue with loading .env "in-time" instead of work-arounds.

Wancieho
  • 708
  • 1
  • 7
  • 25
  • If you're going to markdown at least explain, otherwise your intent comes across as malicious and coward. – Wancieho Dec 06 '16 at 08:22

2 Answers2

0

That's not really a Laravel error.

You should set a default date.timezone in your php.ini file, that will take care of your warning.

On top of that, instead of doing the ini_set in your AppServiceProvider, use 

'timezone' => env('TIMEZONE', '[whatever default value you want]'),

in config/app.php

Robert
  • 5,703
  • 2
  • 31
  • 32
  • I know about Laravel's config and I can't use it in this scenario. Our environments have a specific reason for needing the timezone set in .env. This timezone example is only 1 example of a configurable not loading from .env so this isn't a fix to my problem but rather another solution which I can't use. – Wancieho May 04 '16 at 12:33
  • That doesn't change the fact the date.timezone should have a default value in your php.ini, your example is the specific error message you'll get when you don't. I think I did see your issue before with local dev, env values returning old values when changed, as if they were cached. Is that what you are seeing? – Robert May 04 '16 at 13:54
  • Sometimes its as-if the .env isn't being read in-time and a blank value is passed to the ini_set() inside AppServiceProvider and that throws the Laravel exception. Maybe timezone isn't the best example because of the php.ini setting but this issue has appeared with other custom .env variables aswell. Example we have another variable declared as: MSISDN_PREFIX=0027 which on occasion has also not "loaded" and some of our script breaks. This issue appears maybe 1 in 50 page loads. – Wancieho May 04 '16 at 14:36
  • The env is read only once at boot, unless it's cached. Do you use config caching? (which still doesn't explain the 1 in 50) Or do you have code in place that modifies the env file or paths in any way while booting the app? Not sure if it's Laravel or Dotenv related. – Robert May 04 '16 at 15:46
  • 1
    I found the problem and posted an answer if you are curious. – Wancieho May 06 '16 at 15:34
0

On the same project we recently started running some concurrent AJAX requests. The problem manifested 10 fold but at the same time it got me thinking from a different angle. I then Googled "Laravel multiple AJAX requests error" and found this: Laravel 5 losing sessions and .env configuration values in AJAX-intensive applications

Seeing this made me realise I have exactly the same problem. It's not the fact that i'm using the .env as a "configurable", it's actually 2 problems which are similar but have the same core issue: file read/lock access. My sessions were also acting up because we don't have DB access in our application so we have a heavy dependancy on storing and retrieving data from sessions variables (file system). Although im not sure the issue is related to lock files.

I'm using getenv() a lot throughout my application and a basic HTTP call can sometimes fail if an AJAX request is concurrently running as the .env lands up in a locked state i'm guessing.

My solution was to create a singleton that fires in my AppServiceProvider and store the .env data AND my session data in objects (memory). My theory was that once the file has been opened/closed that even if the request was still busy and another HTTP request came in the file would be closed already. From there on-wards I access all my .env variables and session data from the singleton. Now on the rare occasion the issue still appears.

Next issue that i'm sure will come up is when we have too many concurrent users loading the .env but i'll deal with that then.

Update

I decided to write my own script that opens and reads the contents of .env. Not a Single problem since... So as highlighted in my linked post, PHP dotenv by Lance Vucas seems to have issues on heavy AJAX driven projects. It may be a core PHP issue that is affecting this plugin.

I also never changed anything for my apparent session issues and since implementing my own script the session issue has also disappeared...

Community
  • 1
  • 1
Wancieho
  • 708
  • 1
  • 7
  • 25