Build Your Own PHP Framework
This episode is for members only

Sign up to access "Build Your Own PHP Framework" right now.

Get started
Already a member? Sign in to continue
Playing
12. Using env files

Episodes

0%
Your progress
  • Total: 4h 45m
  • Played: 0m
  • Remaining: 4h 45m
Join or sign in to track your progress
01. Setting up
01. Introduction
2m 23s
0%
02. Composer and PSR-4 Autoloading
6m 17s
0%
03. Bootstrapping and structure
3m 18s
0%
04. Error reporting with Ignition
3m 49s
0%
02. Container
05. Using a container
3m 21s
0%
06. Adding service providers
5m 23s
0%
07. Autowiring with reflection
5m 5s
0%
08. Refactoring to a singleton
4m 17s
0%
03. Application config
09. Building the Config class
6m 19s
0%
10. Reading and merging config files
6m 21s
0%
11. Registering service providers through config
2m 13s
0%
12. Using env files
6m 26s
0%
04. Routing and controllers
13. Everything starts with requests
6m 52s
0%
14. Adding routing
5m 27s
0%
15. Responding in routes
4m 13s
0%
16. Cleaning up responding
7m 12s
0%
17. Defining routes in a separate file
3m 10s
0%
18. Creating a controller
5m 17s
0%
19. Using services inside controllers
2m 3s
0%
05. Views
20. Installing Twig
6m 22s
0%
21. Rendering a view
3m 36s
0%
22. Debugging in Twig
4m 45s
0%
23. Creating a base layout
3m 38s
0%
24. Page titles in Twig
4m 31s
0%
25. Creating a Twig config helper
8m 57s
0%
06. Database
26. Setting up and querying the database
13m 29s
0%
27. Working with models
4m 32s
0%
28. Creating an example user profile page
5m 49s
0%
07. Authentication
29. Setting up Sentinel
8m 36s
0%
30. Creating the registration flow
5m 44s
0%
31. Registering and authenticating a user
5m
0%
32. Showing authenticated state
5m 40s
0%
33. Logging in
3m 59s
0%
34. Logging out
3m 2s
0%
08. CSRF Protection
35. Protecting routes with CSRF
7m 51s
0%
36. Adding tokens to forms
6m 5s
0%
09. Flashing messages
37. Basic session flashing
5m 46s
0%
38. Creating a Twig helper and flashing globally
1m 39s
0%
10. Validation
39. Validating the login form
6m 40s
0%
40. Manually adding validation errors
1m 24s
0%
41. Validating the registration form
4m 5s
0%
42. Custom validation rules
9m 39s
0%
11. Middleware
43. How middleware works
5m 41s
0%
44. Adding auth middleware and grouping routes
7m 37s
0%
45. Persisting old form data
6m 53s
0%
12. Exception handling
46. Creating an exception handler
3m 38s
0%
47. Custom 404 (and other error) views
7m 27s
0%
48. Rendering views for CSRF errors
5m 18s
0%
13. Pagination
49. Paginating with Eloquent
7m 48s
0%
50. Building a pagination view with Twig
7m 38s
0%
14. Global helpers
51. Registering functions with PSR-4
1m 50s
0%
52. Container resolution helper
2m 24s
0%
53. View and config helpers
4m 12s
0%
54. Route generator helper
4m 34s
0%

Transcript

00:00
When you build any application, it's a really good idea not to include config directly in your code and instead have an individual file, one that exists on your local machine and one that exists on any other environment that you deploy to with different config values. Now, at the moment,
00:18
we have got our name of our app registered directly within our code. What we're going to do is switch this up to use environment variables so we can read these locally and on the server with different environment files. Now, if you've not worked with EMV files before, this might be a little bit confusing, but I'll do my best to explain how this works. OK, so just to test this
00:41
out, I'm also going to add in a debug option in here. So I'm going to say debug true since we're working on a local environment. If we deploy this to production, we don't want debugging on because if something goes wrong, we don't want to show errors to the users of our application. So how are we going to switch this up to change this value when we're in a different environment?
01:05
Well, that is using an EMV file. So in the root of our project, we're going to create out a new file called dot EMV. And in here, we can define out any environment variables that we want to register. So, for example, app name, we're going to call this no framework and really importantly, app debug. And on the local machine, we're going to set this to true so that they are our
01:31
environment variables now. Now, locally, we can keep this EMV file and then in production, we can create an EMV file in the root of our project specifically on our server and change this over to false. And we don't want to commit this to any source control, which is why in the get ignore file that I created a little bit earlier off camera, we have EMV being ignored. So this won't be pushed
01:56
and people won't see any of our configuration values. OK, so we've got our EMV file, but the question is, how do we actually use this? Well, if we go over to this PHP dot EMV library, we're going to pull this in. This will read all of our environment files for us and then we can start to use them in our apps. So let's see how this works. OK, so we'll first of all go ahead and
02:18
pull in the package. OK, so let's go ahead and pull this into our project and just wait for this to finish. And then over in Bootstrap and app where we're doing the majority of our setup stuff, the first thing that we want to do up here is load in these environment variables. So let's say dot EMV and we'll use this new library dot EMV just here and just make sure we pull this in at
02:41
the top here if you haven't already. And we're going to create an immutable with the location to our EMV file or the location where this actually lives. So this is just back a directory. So let's go back a directory into the root of our project and then we can say dot EMV and load. That is all we need to do now. So what we have done is this package is now going to load in our
03:05
EMV values. They will exist as environment variables on our server, either in local or production. And then we can use a helper to actually pull these in. So as an example, let's say EMV app name. Let's kill the page here and we'll just go ahead and dump this out. Like this. And if we head over to our app, there we go. So that's the name of our app just by using
03:32
this EMV helper from the package. So now what we can do is over in our config, some of these values are OK. So the name of your project isn't really sensitive. We don't really care if we're pushing that to source control or if that exists within our code, but we can switch this over regardless. So let's say EMV and app name and really importantly, debug app debug. And there
03:59
we go. So now that's going to work in exactly the same way. If we go over to our bootstrap file here and we just var dump on any of our config. So let's grab from the container our config instance and we'll say get app debug. That should be true, which is just here. But then over in our EMV file on the production environment or any other environment,
04:26
if we change this to false, that's still going to grab that value back. So what we're doing is combining config like this, which is really useful just for fluent access to config files. And we're combining that with reading directly from EMV files. OK, now that we've done this, what we can do is look at something that we mentioned earlier, and that is over in our
04:50
app service provider. We only want to do this when debug is enabled. We don't want to register ignition on a production environment when debug is set to false because otherwise we'll be showing errors to the user. So in here, what we can do is just wrap this in an if statement. So pull this into the block here and we're going to grab our container. So let's say this get
05:12
container or we can say get or just container. So that will just give us our container back and we can say get config. And we can say get app debug. So if this returns true, then we register ignition. Let's go over and give this a refresh. And I think let's just say get container and try that again. OK, yeah. So nothing is showing at the moment. So make sure we import
05:39
our config class. And there we go. Great. So this is now only going to be available when debug is set to true. Let's test that out by just going over and causing an error. We could probably do that over in our core app file here. So let's again go ahead and dump on something that doesn't exist. So let's say this name. Let's give that a refresh. We get our nice ignition error page.
06:05
But like I said, on a production environment over in EMV, if this is set to false, we should now not see anything. Error reporting is turned off and it just fails gracefully. And of course, we can fix that up whenever we get a chance. OK, let's go back over to core and app, get rid of this var dump here, and we now have environment variables working.

Episode summary

In this episode, we're tackling environment variables and .env files—basically, how to move your app's config (like app name, debug status, etc.) out of your code and into a separate, secret file. This is super helpful for keeping things like API keys or environment-specific settings out of source control and letting you easily change them between your local dev machine and production.

We start by explaining why you shouldn't hardcode config into your app, and how a .env file lets you keep things flexible and secure. Then, we set up a .env in the root of our project, add some values (like APP_NAME and APP_DEBUG), and make sure it's ignored by git so it doesn't get pushed up with your code.

Next, we install a PHP package to read our .env file, so we can load those environment variables in our app. We wire this up in our bootstrap process, making them available everywhere. Then, we show how to fetch these values in your config (using a helper method), and why that's a better approach than hardcoding.

We also look at contextually enabling stuff based on your environment—like only turning on your fancy error pages if debugging is enabled, but hiding them from real users in production. There's a live test breaking the app to see error handling in action, toggling between dev and production settings in the .env file.

By the end, you'll have your app reading config from .env, so it's much easier to manage and way safer!

Episode discussion

No comments, yet. Be the first!