So the simplest example is a database connection. So we're going to take a look throughout this video at why we should get into the habit of taking the configuration, any kind of configuration, and moving it away from our code base. And we're talking about this in terms of storing your code on some kind of version control

service like GitHub. So even if you don't do this, it's a good habit to get into, particularly if you're sending your code around to different people. So to start out then, let's take a look at how we would normally do this.

Now I'm using a framework to demonstrate this, but you really don't have to be using a framework. The package that we're going to be using is really straightforward to use pretty much anywhere you want. So I'm using Slim.

I'm just booting up an application. I've created a route here for the homepage, and all I'm doing is returning home. You can see that just over here, and we're just running our app down here. So to bind our database connection, for example, to the container, we would start by just grabbing

the container from Slim. So we'd use something like get container, and then we would just bind this on. So we might call this DB, and in here we have our binding. And in here, we would just return a new PDO instance.

And normally what we would do is choose the driver. We'd go ahead and choose the host. So that might be local host. We'd go ahead and choose the database name.

In my case, this is project. And of course, we would enter in our username and our password. Now even if you are storing these credentials in some kind of configuration file, it's still worth noting what we're going to do within this video because it does differ.

So this is our PDO connection. What we could do now is maybe grab a list of users. So we could say this DB query, and go ahead and pull these in. So we could select all of these from the users table.

I just have a very basic table set up. And we could say respond with some JSON, and from that query, we could fetch all of them results and fetch them perhaps as an object. So this would look like the following.

And of course, here we would just say users like that. So now we have three users coming through. That's beside the point. So what we're doing here then is we are putting our configuration directly into our code.

So why is this not a good idea? Well let's say that at some point, you either send your code around to someone else, or you open source your application. Or even if you were to just paste this line of code or these few lines of code into a

forum somewhere. Of course, it just gets a little bit tricky, the fact that you are hard coding all these values into your code, and the security problems here are obvious. So let's say then you do push your project up to version control.

Let's say you push it up to GitHub. Your configuration will be visible to everyone. And what you don't want to have to do is keep changing these values when you push this up. So for example, if someone were to pull down your project to contribute on, they should

be able to have their own local configuration and go ahead and get started. So just as an example then, over on GitHub, the CodeCourse website, if I were to open source this tomorrow, or even now, no one will be able to see any configuration, any kind of secure details about the services that we use, like private keys, or database

passwords, or database names, any of that kind of stuff. So I could literally open source this now, and there would be absolutely no problem at all. So that's kind of the point.

We want to be in a position where we could do that, and it would just work, and it would be secure. So the question is then, how do we actually do this? Well, what we're going to be doing is looking at storing our configuration in environment

variables. And we're going to use a library called php.env to go ahead and load environmental variables from a .env file. Now if you've worked with Laravel, you will recognize the .env file.

It's exactly the same. Laravel will use this package to basically take your configuration from this file, which you do not have to commit to source control. So we have an example project here that I've set up.

What we're going to be doing is writing out some code, and we're going to be pushing up our project to version control just so you can see how this works. So let's start by just pulling in this library then. Let's go and find the name.

So it's this just here. I'm going to go over and just require this into my project. If you're not using a framework and you're not using Composer, you can go ahead and grab Composer just to do this if you want.

It makes sense to have this in here. Otherwise, it's always a good idea to use Composer for everything. So we've pulled down this project then. Let's take a look at how easy this is to use.

So somewhere within your project, it doesn't really matter where it is, we can go ahead and we can load in our configuration. So if we just say set this into a variable called .env, we can just say new.env.env, and then here we choose the directory that we want to load from.

In this case, it's just the directory that I'm currently in, but of course, this might differ. And then all we want to do is say load. Now that is literally it for this library.

We don't really need to do much else with it. So what's next then? How do we kind of take this configuration and place it somewhere that we don't have to commit to source control?

Well, we go ahead and create a .env file. So let's create that in there like so. And now what we can do is create all of our configuration in here and then load it into here.

And then we'll take a look in a minute at pushing this up to GitHub. So for example, for our database configuration, we have a host which could vary between servers. So this is another reason to use this. It means that if you have different configuration on different servers, let's say you have a

production server, a staging server, and then you have your local environment, the configuration between all of these can be different just by having a different .env file. So it helps to have these in there as well for that reason. And of course, this doesn't mean that you don't have to have some kind of configuration

helper, but all you want to do is take the configuration from here and place it into your configuration helper, and then you can use that however you want in your project, much like Laravel does if you're used to working with Laravel. So how do we fix this up then?

Well, let's go ahead and define out what we want in here. Of course, this list could be endless, any services you want. But for now, let's just say we're going to deal with our database. So we have a database host.

We would have a database names. This would be the actual database, in my case, it's project. And then, of course, more importantly and more importantly for security considerations, we have a username here and a password.

Mine happen to be Homestead and Secret. So let's just add these in here, so Secret. And there we go. That is pretty much it.

So now, with this beautiful library, what we can actually do, we can test this out down here by just killing the page. We can use getenv, and then we can go ahead and choose the name of that environmental variable.

So, for example, if it were dbUsername, we just say dbUsername. When we go ahead and check this out in the browser, we see that in there. So everything is really nicely done. It's just so simple to use, which is great.

So now, the job is just to replace anywhere in our project that we are pulling configuration in with this function. And there are a load of other ways that you can do this. You can, of course, use your server, SuperGlobal, to do this as well.

This will work if you were to do this. And what you can also do is with your request in here, you can also say something like request get and then use that in there as well. But there are tons of different ways that you can do this just depending on how you

want to do this. So we're going to say getenv for our hostname, so this is dbHost. We can grab this for our database name as well, so getenv dbDatabase. And then, of course, our username and our password as well, so getenv dbUsername.

And we can have exactly the same thing here for our password, so dbPassword. So let's first of all check that this still works. And you can see it does. So we're just pulling these in.

It works in exactly the same way. So now then, we're in the position where we want to push this up to version control. And of course, what I can do is go ahead and initialize a project within here. And I can go ahead and check the status of this.

So we have a few things that obviously we don't want to commit. We have these annoying dsStoreFiles on OSX. We have our environment file, which contains our configuration, which of course we do not want to commit.

And of course, we have things like the vendor folder, which we don't want to commit to source control either. We want this to be installed on the server only. We don't want to have to keep pushing up the changes here.

So to deal with this then, we create a gitignore file. So let's just go ahead and create this in here. It's just .gitignore. And in here then, we just place either directories or patterns of things we want to ignore.

So in this case, it's dsStore we want to ignore. And we want to ignore our .env file. So now when we run git status, you can see that the only things we're pushing up are our gitignore file, our composer.json file, our composer.loc file, and index.php and of

course any other files that you have within your project. So now we can actually push these up. So let's go ahead and just commit and say first or let's add these changes in first. So git add and then we'll go ahead and commit here with a message.

So let's say first commit. And let's go ahead and pull in our project. So let's just add this remote repository and we can go ahead and now push to our project. And there we go.

That's being pushed up. Great. So we now have all of our stuff in here that we need. Perfect.

So we have our project in here but there's nothing in here that gives away anything that could potentially cause some kind of security issue. There's nothing in here at all. So that is pretty much it.

We've basically covered pushing up to source control with no configuration in here whatsoever. So what you'll want to do then is depending on how you're deploying your project, you can actually specify your environment variables which will then be loaded in and they'll be used by your project.

That's a little bit out of the scope but for now what I would do is just get into the habit of doing this. So there are a couple of other things. We want to just talk about what happens when obviously someone pulls down your project.

They're not going to see this .env file. So to be able to maybe add their own local database credentials, they're going to have to go through your project and see what you're using and create their own local .env file because obviously by pulling down your project from here, they're not going to have a .env

file. So what we would actually do is to kind of give a clue as to what we're using. We would create a .env.example or .env.dist, whatever you want to call it. So we do this.

We go ahead and take any environmental variables we add while we're locally developing and we just add these in here like empty. So let's say we were to set up mail with Mailgun and we had some kind of Mailgun secret. Well, of course, inside of our own environmental file, we would go ahead and add that secret

in. But then what we would do is in our environmental example file, we would literally take this, paste it in here but without the value, and then we can commit this up to our source control. So if we just go and run git status here, we see that we've got this in here.

So let's go ahead and add this in and go ahead and commit this. So we'll just say added Mailgun support and we'll go ahead and push this up to master. And then obviously when we head over here, we have this environmental example. So when someone pulls this down, they can see, oh, okay, I need a Mailgun account to

be able to test this. I need database credentials and then they can add them in there and it will work perfectly on their local machine as long as they have the correct credentials. So that is pretty much it.

This is a very basic guide to setting this stuff up but it's really important to think about this when you are getting into projects. If I were to open source this, there are no secret details in here that could potentially be seen by anyone.