[Poetawd]

Hello All !

First of all, thank you very much for all the work in CI4 ! I am truly in love with it ! 

I really liked the "env" file approach of having all configs in one file ! It helps a lot !

I just have a couple questions for our CI4 Jedi Masters:

     - Is it safe, and also a good approach, to store our own variables in that file  ? Variables like: "Website Title" or "Default Language" 

     - How to access those variables in our controllers or models ?

Also, for those who are starting, I had to rename the "env" file to ".env" in order for this to work.

Thank you !

[dave friend]

As I understand it the .env file is designed to be used for development environments where certain config items will be different from the production environment, e.g. base_url, database settings, etc. The .env file should NOT be used in a production environment.

The config files hold all the production settings and any custom variables that are the same in both environs.

[Poetawd]

Wow ! Thank you !

Good point! And would be great to hear from others about this...

The .env file shouldn't be used in a production enviroment ?

I mean, there is nothing about that on the User Guide: https://codeigniter4.github.io/userguide...ation.html

Answering my own question:

To use variables defined in .env file:

Variable: S3_BUCKET="dotenv"
Usage:

$s3_bucket = getenv('S3_BUCKET');
$s3_bucket = $_ENV['S3_BUCKET'];
$s3_bucket = $_SERVER['S3_BUCKET'];

[dave friend]

I think the idea that .env is not for production is something I decided would be my practice. There's no technical reason not to use it for production. To my thinking, .env is used to override the "real" settings as defined in the config files. Not using .env for production simplifies production deployment. I like not having to juggle multiple versions of .env files.

[MGatner]

Avoiding .env for production is fine but certainly not a requirement nor a best practice. The point of the .env is two-fold:
Provide a way to differentiate settings across multiple environments, and provide a secure location (e.g. not included in version tracking) for sensitive data. If your variables you want to add fall into either of the categories I’d say it’s a good place. If you’re looking to use it simply as an easy way to load common settings I’d recommend using a
Config file instead, as they are only loaded on-demand and have a lot more flexibility as to what you can put in them.

---

As for accessing variables, use the env() command you make it super easy.

https://codeigniter4.github.io/CodeIgnit...s.html#env

Also check out https://codeigniter4.github.io/CodeIgnit...ments.html

[Poetawd]

Avoiding .env for production is fine but certainly not a requirement nor a best practice. The point of the .env is two-fold:
Provide a way to differentiate settings across multiple environments, and provide a secure location (e.g. not included in version tracking) for sensitive data. If your variables you want to add fall into either of the categories I’d say it’s a good place. If you’re looking to use it simply as an easy way to load common settings I’d recommend using a
Config file instead, as they are only loaded on-demand and have a lot more flexibility as to what you can put in them.

---

As for accessing variables, use the env() command you make it super easy.

https://codeigniter4.github.io/CodeIgnit...s.html#env

Also check out https://codeigniter4.github.io/CodeIgnit...ments.html

Thank you !

[kilishan]

For a bit of background of where .env files came from originally (though other frameworks are also currently using them.), see this 12 Factor App explanation.

[John_Betong]

A long time ago on this site someone suggested testing to see if the site was being run on LOCALHOST and if so to define a logical constant. I adopted this tactic and now all files have both local and remote settings such as database login details of whether to display advertisements, analytics, etc. Gone are the days when a specific localhost file overwrote online pertinent information I am delighted to say

Is it possible to have a single env file which caters for both online and online settings?

[InsiteFX]

Most servers will see a .file as a hidden file so nothing to worry about.

[dave friend]

Most servers will see a .file as a hidden file so nothing to worry about.

Plus, due to CI4's file structure .env is in a folder that is not accessible via HTTP. (Or at least that's the way the folder should and is expected to be.)