Alright, let's knock out some of the more quick changes in Laravel 5.7. Here you can see I have an installation of Laravel 5.6 installed, and if I go to my resources directory, this is what you'll be used to. Now in your assets directory is where you'd store all of your JavaScript, your Vue components, things like that, and then of course your Sass or your Less or your Scss would go here. However, if I switch over to a new project, Laravel 5.7, if we open it up, we'll see that now that assets directory has been extracted. So now you'll find your JS directory and your Sass directory as direct children of the resources folder. You know what, I think this is a little bit cleaner.

folder. You know what, I think this is a little bit cleaner. It's one less folder to dig down. Now if you're wondering, as part of your upgrade, do you have to change everything, no. You don't have to do a single thing. It's not necessary for your project, but if you'd like, you could move those to your resources directory, and then if you're using something like Laravel Mix, just make sure that you update the file paths as you see here. Okay, what else? What about action URLs?

Okay, what else? What about action URLs? I'm going to go to my routes file, and you can see I have two routes for static pages, an about page and a contact page. Now you may not know this, but there is a way to generate a URL to a controller action using this action helper. So for example, if I said PagesController, and I'm going to go to the about method, let's just return that as a string and see what we get in the browser. All right, and sure enough, we get a URL to the about page, and the same will be true for any action that you have registered, like this one.

All right, and sure enough, we get a URL to the about page, and the same will be true for any action that you have registered, like this one. Refresh, and that takes us to the contact page. Now as part of this helper, if you have any additional parameters, like you have to send through a username or an ID or something like that, you would pass it through as the second argument. Now this has been around in Laravel for a very long time. However, if you want just a small addition, you could instead use a more callable-like syntax. We're going to the PagesController.

syntax. We're going to the PagesController. Let's import that, and specifically the about method, or the about action. Okay, this will give us the same thing. Useful, right? Now if I switch to the Laravel 5.6 project, you can see I have the exact same thing here. However, it of course won't work. It blows up. So yeah, in terms of which option you use, or whether you use the Action Helper at all, entirely up to you.

So yeah, in terms of which option you use, or whether you use the Action Helper at all, entirely up to you. Some people prefer this approach, especially if you use an IDE like PhpStorm, because it allows you to click directly to the controller. Okay, one last thing. Let's talk about authorization against guest users. So if I make a GET request to post/{somePost}, I'm going to load a PostController in a show method. And if I go to PostController at show, you can see all I'm doing is returning the JSON representation of the post.

And if I go to PostController at show, you can see all I'm doing is returning the JSON representation of the post. So if we visit that, we get one post, two. We're using basic route model binding there. But now imagine you need some authorization there. These are special. These are top-secret posts, and not everyone should be able to access them. All right, well maybe you're going to use the GET facade, and you'll say, I'm going to authorize whether you can read this post. Like so.

to authorize whether you can read this Post. Like so. Now at the moment, this doesn't exist. There's no logic, so it's going to blow up for everyone. Or not blow up, but a 403 will be returned for everyone. Let's go to my AuthServiceProvider within your app/Providers directory, and let's just do one right here. We'll say GET. Let's pull in the Facade there. And we'll define whether or not you can read a given Post.

Let's pull in the facade there. And we'll define whether or not you can read a given post. That'll accept the user and the post. And to start, we're just going to return true. Now as you may know, in Laravel 5.6 and below, any person who is signed in will be able to access it. And if you're not signed in, well, it just returns false by default. Which means if I give this a refresh, I'm not signed in, so I still get a 403. To test this out, let's simulate a signed in user. Just right here, I'll say LOGIN, using ID, and we'll grab whichever user has an ID of

To test this out, let's simulate a signed in User. Just right here, I'll say LOGIN, using ID, and we'll grab whichever User has an ID of 1. Okay, so now we have a signed in User, which means we will hit this logic, and we're just returning true, so anyone has access. All right, give it a refresh, and we see the result. Okay, so new in Laravel 5.7 is the ability to execute this logic even for guest users. We do that through a nullable type hint. So let's import our User, and we're going to specify that this is a User or null, or a guest User.

So let's import our User, and we're going to specify that this is a User or null, or a guest User. So now, let's give it a shot. Just to be explicit, we will log out anyone currently in a session. And if we come back, refresh, even though we're not signed in, we still were able to access that logic. Again, one more time here, if we did not declare that to be nullable, it would not be accepted. We'll get a 403. So this means if you have situations where you need to define authorization even for guest Users, maybe you're checking their IP address, or some kind of basic auth, or something.

So this means if you have situations where you need to define authorization even for guest users, maybe you're checking their IP address, or some kind of basic auth, or something that you threw in the session, it doesn't matter what it is, on the condition that you need to authorize not just registered users, but also guest users, you now have the ability to do that. And if you're not familiar with nullable types, you can review that more. I believe it was released as part of PHP 7.1. Alright, so that'll do it for the big important updates to Laravel 5.7. So onward to 5.8.