The next thing you're going to notice is that all of the middleware that has existed in the app/Http/Middleware directory by default in Laravel is no longer present in new Laravel installations using Laravel 11 or greater. The thought process behind this, again, makes sense. We very rarely touch any of this middleware. We leave it as is, so it's been moved down into the foundation level and will be enabled by default. But what if you want to configure some of that middleware? For example, the TrimStrings middleware takes any input from the front end and removes whitespace from either end because it's almost always user input error, but by default will not do so for current_password, password or password_confirmation fields. In the past, if you've wanted to add a field, well, you just edit the except array. So maybe secret can be added to this array as well. How would we do that in Laravel 11? We can make changes like that from

if you've wanted to add a field, well, you just edit the except array. So maybe secret can be added to this array as well. How would we do that in Laravel 11? We can make changes like that from the AppServiceProvider. In the boot method, we need to pull in the middleware from Foundation that we're interested in. In this case, it's TrimStrings. And let's just take a look at the namespace, Illuminate\Foundation\Http\Middleware\TrimStrings. The name is identical. And you'll find that TrimStrings has a brand new except static method applied to it that we can use to extend any properties we want to avoid trimming when the request comes in. So we would just add secret here and everything else would work just as it used to before. Another example of middleware that we might have changed in the past is RedirectIfAuthenticated. And it was quite common practice to update this RouteServiceProvider HOME constant so that we could change where you will be sent.

that we might have changed in the past is redirectIfAuthenticated. And it was quite common practice to update this RouteServiceProvider home constant so that we could change where you will be sent if you were indeed authenticated. How do we do that now? After all, there is no RouteServiceProvider. So it's not going to be able to find that particular constant. Well, again, we can make use of redirectIfAuthenticated. And we pull that in from Laravel, not from our local project. And then we can use the redirect using the static method, which accepts a closure that receives the request and is expected to return a route to wherever you should send somebody who is authenticated. Maybe that's the home route. Maybe that's the dashboard route. You decide, but whatever the case, this is how we would configure it now instead of in our RouteServiceProvider. Of course, all of this applies to built-in middleware, but what about middleware that you

but whatever the case, this is how we would configure it now instead of in our root service provider. Of course, all of this applies to built in middleware, but what about middleware that you want to build? You can use php artisan to create custom middleware as before. php artisan make:middleware. Why don't we have, I don't know, LogRequest endpoint. It's going to place that middleware exactly where you'd expect in the HTTP middleware directory. If we open that up, well, everything looks exactly the same. Why don't we go ahead and use the Log facade in order to log some info, the request URL in this case. Yeah, you wouldn't create this middleware in real life, but it gets the point across. Now, again, previously, if we take a look at a Laravel 10 application, you would register middleware like this inside the Kernel, but looking at the skeleton for Laravel 11, the Kernel is nowhere to be found. In fact, if you search for kernel,

you would register middleware like this inside the kernel, but looking at the skeleton for Laravel 11, the kernel is nowhere to be found. In fact, if you search for kernel, you won't find a kernel file at the application level. Instead, we can register middleware like this in app.php under bootstrap. You may have avoided the bootstrap file in the past, but Laravel 11 changes that perspective. In fact, app.php is where you will configure most things for your Laravel application. Inside this file, you'll note we have several helper methods that set up providers, routing, middleware exceptions, and as you'd expect, middleware is what we actually want to make use of here. So imagining that we want to append our log request endpoint middleware to the web middleware group, I would take this middleware parameter we've been given, call web, and pass in the log request endpoint fully qualified class name, and that's it.

middleware to the web middleware group, I would take this middleware parameter we've been given, call web, and pass in the logRequest endpoint fully qualified class name, and that's it. With that in place, if we visit the landing page, the Laravel splash screen for Laravel 11, and then we come back and open up laravel.log, well, I would expect, yeah, here we go, the URL that we visited. If I do it again, maybe a second time, and we go and look once more, now there are three entries in our log. So that's how we can configure middleware. Note that the second item is prepend. So if rather than adding the middleware to the end of the web stack, we wanted to prepend it, you could use name arguments to do that very easily. And you can also add an array here if you want to add multiple middleware items to a particular stack. Whilst we're on the topic, it's worth briefly mentioning that the exception handler is also gone in Laravel 11. So in this

want to add multiple middleware items to a particular stack. Whilst we're on the topic, it's worth briefly mentioning that the exception handler is also gone in Laravel 11. So in this Laravel 10 application, perhaps you've been used to using the don't flash array or registering renderable exceptions like this GitHubFailedToRespondException inside the register method at the bottom. Well, in Laravel 11, you're going to do all that work inside the bootstrap/app.php file in the with exceptions callback. So we can say exceptions.don't_flash, and you can add any attributes there. We could say exceptions.renderable, and we could set up our exception render callback here. You can also do reportable. All of the functionality remains the same. It's just moved from a handler to this single callback.

It's just moved from a handler to this single callback.