The latest version of Laravel, version 5.8, has recently been released. This version has many exciting new features and it is a continuous improvement of previous versions of Laravel. These features include:
Artisan::call
improvementsorWhere
Eloquent methodAnd many more. In this article, I will discuss some of these new features in greater depth.
Policies are one of two primary ways Laravel handles user authorization. They are classes that organize authorization logic around a particular model or resource. In the previous version of Laravel, policies needed to be registered in the AuthServiceProvider
as follows:
In this case, the policy we are registering is a policy called TransactionPolicy
, which we are entering into the $policies
array.
However, starting in Laravel 5.8 you do not need to manually register a model’s authorization policy. Laravel can auto-discover policies as long as the model and policy follow standard Laravel naming conventions and the policy directory is in its default location.
If you have models or policies in locations different from the default Laravel structure, you can register a custom callback using the Gate::guessPolicyNamesUsing
method. Typically, this method should be called from the boot method of your application’s AuthServiceProvider
like this:
Carbon is a package that extends PHP’s own DateTime class and makes working with dates and time very easy. Laravel 5.8 provides support for the 2.0
release of Carbon. Among the new features of Carbon 2.0
is the CarbonImmutable
class and a new Date
facade. Let’s see how this works.
Enter the following in the routesweb.php
file of a Laravel 5.8 installation:
Here we are creating a route carbon
which would save the current date in a $date
variable and then display it. It then adds three (3) days to the current date and also displays it. If you visit the /carbon
route we have just created, you would see something like:
What is happening here is that we are changing our object. This may be what you desire, but in many cases, this is not what we want, as dates are usually protected
properties. We should actually be able to create a new date and not modify an existing date. For example say we are storing a date of birth in one of the columns of our database, this is not information that is going to change, however, we may create a copy for it and do some modifications to that copy. This is where the CarbonImmutable
class comes in. To use this feature, go to your AppServiceProvider
and enter the following:
Then update the routesweb.php
file to use the new Date
facade and create a copy of the date which we can change:
Refresh your browser and you should see this:
Laravel 5.8 introduces a new eloquent relationship: HasOneThrough
. Though this is new in Laravel, it exists in other frameworks like Rails. Say we have three models: a Supplier
model an Account
model and an AccountHistory
model. A supplier has an account and an account has one account history.
Previously to get a supplier’s account history, you will have to find the supplier then write something like: $supplier->account->accountHistory
. Now you may use a hasOneThrough
relationship to skip this step, accessing a supplier’s account history straight away like this: $history = $supplier->accountHistory
through the account model:
A little known fact about Laravel API authentication is that you don’t always have to use Laravel Passport. There is a simpler token guard which provides basic API authentication and in Laravel 5.8 it now supports storing tokens as SHA-256 hashes. This provides greater security over storing plain-text tokens.
In previous versions of Laravel, caching was set in minutes. This has changed in version 5.8, to seconds for more precise and granular setting for expiration time when storing items and provide compliance with the PSR-16 caching library standard. So in any reference to cache in your application remember to update to seconds:
In Laravel you can define your timezone for a scheduled task using the timezone
method like this:
In previous releases, you have to repeat this for every scheduled task and this can quickly become cumbersome if you have many of them. In Laravel 5.8 you can just define a method called scheduledTimezone
in your app/Console/kernel.php
file and return your default timezone. This will be attached to every scheduler you have:
Laravel allows you to make Artisan commands from your code using the Artisan::call
method. In previous versions of Laravel, if you need to pass some options to the command you typically do this:
Now in 5.8, instead of passing the options as an array, you can pass it in one single string like this:
A way to quickly serve your Laravel application is by running the command php artisan serve
. In previous versions of Laravel this command will run your application in a default port of 8000
and if you attempt to serve another application with the same command, this would fail. Now in version 5.8 the serve
command will scan for available ports up to port 8009
so you can serve multiple applications at once.
This is another improvement to make your test code cleaner and readable. Say we want to mock a transaction service and have it return some dummy transaction data. In previous versions of Laravel we would write something like this:
In Laravel 5.8 this can be shortened to:
This takes care of calling Mockery
and binding it into the container. Notice we don’t have to call $this->instance
Previously if we wanted to combine scoped query with or
 , we typically would define a closure like this:
Laravel 5.8 introduces a “higher order” orWhere
method, so you don’t need to write the above closure anymore. Instead, you can write this:
This new version of Laravel comes loaded with many exciting features and we have gone through some of the most notable improvements in the framework. For details on how to upgrade your existing Laravel application to version 5.8, see the upgrade guide. What are your thoughts on Laravel 5.8? Let me know in the comments section!
If you want to learn more about Laravel’s new features check out the following resources:
Install LogRocket via npm or script tag. LogRocket.init()
must be called client-side, not
server-side
$ npm i --save logrocket // Code: import LogRocket from 'logrocket'; LogRocket.init('app/id');
// Add to your HTML: <script src="https://cdn.lr-ingest.com/LogRocket.min.js"></script> <script>window.LogRocket && window.LogRocket.init('app/id');</script>
Would you be interested in joining LogRocket's developer community?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up nowNitro.js is a solution in the server-side JavaScript landscape that offers features like universal deployment, auto-imports, and file-based routing.
Ding! You got a notification, but does it cause a little bump of dopamine or a slow drag of cortisol? […]
A guide for using JWT authentication to prevent basic security issues while understanding the shortcomings of JWTs.
Auth.js makes adding authentication to web apps easier and more secure. Let’s discuss why you should use it in your projects.