I am new to Laravel and want a simple explanation of the .env and .env.example files, why we need them and the difference between them.
I know that .env is used to specify the app's database connection, for example but I would like to understand it deeper.
.env file, as its name suggest, is a local where you put all your environment setup, such as database credentials, cache drivers and etc. Everything that is about the server that the project is running, and may have different values for different servers, are setup here.
Per example, your local dev environment has different database credentials than production environment. Also your colleague dev environment has different than yours. So each one has a .env with different informations.
And because of these, this file can't be versioned, so .env.example is the file that has every constants setups that .env has but with no values, and only this one is versioned. .env.example works as a guide for creating a .env file with the needed informations that is needs to have the application running.
As you are working with Laravel, you can find more informations here: environment-configuration
The .env file stores configuration variables for your application and .env.example is simply an example of what might be in the .env file! You can easily rename .env.example to .env to get started.
What are configuration variables? From The Twelve-Factor App
An app’s config is everything that is likely to vary between deploys (staging, production, developer environments, etc). This includes:
Resource handles to the database, Memcached, and other backing services
Credentials to external services such as Amazon S3 or Twitter
Per-deploy values such as the canonical hostname for the deploy
In Laravel the .env file also contains your app key which is used for encryption in your app. Because of this, and because you will likely store other private keys in this file, ensure you do not commit .env to your source control or share it publicly!
I recommend you read the link above for an explanation of why you should separate configuration from your application and for Laravel-specific information you can look here
.env file contains various settings, one row – one KEY=VALUE pair. And then, within your Laravel project code you can get those environment variables with function env(‘KEY’).
The rule is that .env file is not committed to the repository, so it is really convenient, cause then people on your team can change their variables locally without committing them to the repository.
Now, .env.example file, on the contrary, is included in the repository – it is used as an example file for you to know what KEY=VALUE pairs you need for your project. Most often it is used to copy it to .env file and then change the values.
You can also read about it in the official Laravel documentation.
.env is simply used to store all sensitive files like password API key, database,and so on as environment variables to be used in your code later this sensitive files are not included in the code base and will not be there when been pushed to git.
.env.example
This is a file that tells other programmer what is meant to be in there code when your code is cloned or been used by another user.
Example
.env
API_KEY="hwhhwhshs6585gahwhgwuwjwusuhs"
.env.example
API_KEY="YOUR API KEY GOES HERE"
The .env.example file is just an example of the .env file. It is not used by the app. It's used to serve as a base for you to edit and rename.
The .env file contains constants that are specific to that application to those environments. What this means is for example if I want to deploy my app in multiple places with the same code, I'll just have to change some settings on this file to run on each environment and we are all set, no code changes needed.
These settings can be database connection settings but they can be used for other things too like the APP_KEY that should be different for each application and used my many functions.
Be careful, this .env file should not be shared anywhere as it contains private information about that specific deploy.
You can read more here: https://laravel.com/docs/5.6/configuration#environment-configuration
From the version Laravel 5.0 in your main folder you should have .env file which contains various settings, one row – one KEY=VALUE pair. And then, within your Laravel project code you can get those environment variables with function env(‘KEY’).
The rule is that .env file is not committed to the repository, so it is really convenient, cause then people on your team can change their variables locally without committing them to the repository.
Now, .env.example file, on the contrary, is included in the repository – it is used as an example file for you to know what KEY=VALUE pairs you need for your project. Most often it is used to copy it to .env file and then change the values.
Your .env file should not be committed to your application's source control, since each developer / server using your application could require a different environment configuration. Furthermore, this would be a security risk in the event an intruder gains access to your source control repository, since any sensitive credentials would get exposed.
If you are developing with a team, you may wish to continue including a .env.example file with your application. By putting place-holder values in the example configuration file, other developers on your team can clearly see which environment variables are needed to run your application. You may also create a .env.testing file. This file will override the .env file when running PHPUnit tests or executing Artisan commands with the --env=testing option.
.env or environment variables are files that store some sensitive information like your API key. They are only visible to you on your PC/local system. Not to anyone else, if you push your project to GitHub or some other platform.
.env is a file that store information about your website such as API or database password.
these information are visible for you in local host. when you publish website on a host this file not visible for other people.actually env's file improve security website on the net.
I'm starting with Git and Github for versioning my Symfony3 project and I was wondering why parameters.yml is in the .gitignore file by default? I'm changing that file so that my app connects to a PostgreSQL database.
My concern is that when others clone my project from GitHub and start contributing will it affect them to have the parameters.yml file missing?
Do I need to remove it from .gitignore?
If not when do I have to make it trackable?
Thanks for your answers
From the docs:
The default parameters.yml file... defines the options related to the database and mail server infrastructure.
Each of your servers will have its own infrastructure configuration. No one who clones your project will be sharing your exact server configurations. You also don't want to publish your system credentials to the internet. So this file should be ignored by git.
Instead you want to share a similar file for each user to set up their own parameters:
Symfony includes a configuration file called parameters.yml.dist, which stores the canonical list of configuration parameters for the application.
Whenever a new configuration parameter is defined for the application, you should also add it to this file and submit the changes to your version control system. Then, whenever a developer updates the project or deploys it to a server, Symfony will check if there is any difference between the canonical parameters.yml.dist file and your local parameters.yml file. If there is a difference, Symfony will ask you to provide a value for the new parameter and it will add it to your local parameters.yml file.
Because this file it's going to be generated from parameters.yml.dist when you run composer Update
Is there any way to move config app (app/config) above the app folder?
I want to deploy app folder without override config files on multiple instances of my app.
I am not sure if that is possible. What you can do is adding a (set of) custom config(s) to you config.php's always_load section. You can add custom paths so that it can be loaded from any file, even outside of your application.
While this (partly) solves your problem, I might have a better solution for you:
You can configure your application per environment. APPPATH/config/production/*.php will override your default configuration. If you don't want to version control this folder, you can add it to .gitignore. If your deployment process is smart enough, you can configure to preserve configuration files between deployments. To activate production environment, you need to set the FUEL_ENV environment variable to production.
When deploying a web application in PHP, one doesn't always want your configuration files with passwords to be committed into the repository.
What is the preferred method of handling this, ie.
saving the details in a DB, and templating the config file
copying the file onto the server (which raises the question of where to save
and version the file being copied in)
setting the environment variables on the server, and having the config file reading from
that.
or any other suggestions.
You can have your config files in a folder out of the public folder and restrict the access to that folder using .htaccess file. Of course this works if you are using Apache as webserver.
I am new to GitHub. I managed to install GitHub for Windows and created a github repository. I'm a PHP developer and this is my current situation before GitHub.
Currently, all of my work go to C:\xampp\Dropbox\* ("htdocs"). Everything I code is in there with each application under its own subdirectory. Whenever I need to update the production server, I FTP our production server and upload the necessary files. This is good when I am working alone but working with other developers would be hard because we need to know who edited which, when what was edited, etc.
Could you help explain how I can maintain my codes using GitHub? I suppose that I shouldn't make the entire htdocs as a local repository. I access my codes via http://localhost/ when testing it locally. Since I develop web applications using PHP, code changes regularly. We don't compile codes and I was used to simply saving all the files and letting Dropbox save all the versions I made.
It's a bit confusing what to do next since the GitHub for Windows application created local repositories in C:\Users\Admin\Documents\GitHub\test-app folder. Should I edit the code in htdocs and ALSO edit the code in My Documents\GitHub? Then also "push" the update to GitHub AND also update our production server via FTP?
So, to summarize, from the primitive perspective of web development, what steps must be changed so that I can enjoy the benefits of using version control systems such as GitHub?
Thank you!
The global idea is to use a versioning server to push code directly into your production server, bypassing FTP boring method.
You can tell GitHub application to clone your code at Xampp htdocs root, instead cloning it into your documents, if you have already initialized your repositories.
Every project must be a GitHub (or Git, more generally) repository.
So, you have to :
git init all your projects into your local server, at root of your project (so, not htdocs, but htdocs\<YOURPROJECT>
create repositories on GitHub for each of your projects
Follow GitHub instructions to initialize projects, git push on GitHub to finish.
You can do all that with a command line. In my opinion, it's easier.
Your code is on GitHub now. You won't have to edit your code into your documents AND htdocs if you initialize your repos in htdocs.
Next, it could be "fun" to install Git on your production server to grab most recent code from GitHub repository. Without Git, it's a pain in the a** to push code on a production server.
Now, when your local dev server and your production server are in sync, every time you will commit and push on GitHub, you can grab latest copy with a simple git pull on your production server.