Laravel 5.2 .env sometimes doesn't load in tim

2020-05-05 17:16发布

问题:

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.

回答1:

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



回答2:

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...