We're live-coding on Twitch! Join us!

Laravel has come a long way becoming better with each new release. During the recent Laracon Online, Taylor Otwell announced the official release of Laravel 5.6. Unlike Laravel 5.5 which required PHP >= 7.0.0, this new version will require PHP >= 7.1.3.

Without further ado, let's see what this new version of Laravel has to offer:

Two New Blade Directives

Laravel 5.6 will include two new form blade directives for cross-site request forgery (CSRF) and HTTP method input.

In previous Laravel versions, we had to do this at the top of forms to create hidden inputs for the CSRF token and the spoofed HTTP method:

  {{ csrf_field() }}
  {{ method_field('PUT') }}
  <!-- ... -->

With the new release, it's now possible to do this instead:

    <!-- ... -->

Note: HTML forms can’t make PUT, PATCH, or DELETE requests you need to add a hidden method input to spoof these HTTP verbs. Laravel uses the method input to route the request to the appropriate controller action correctly.

I find these directives looking neater and easier to remember. However, the old helper functions are still available for use if that's what you prefer.

The Artisan Optimize Command Has Been Removed

The Artisan optimize command was deprecated as of 5.5 and has been removed officially from 5.6. Quoting Laravel 5.5's upgrade guide:

With recent improvements to PHP op-code caching, the optimize Artisan command is no longer needed. You should remove any references to this command from your deployment scripts as it will be removed in a future release of Laravel.

In the case you want to upgrade to this new version, be sure to remove the command from your composer.json post-install-cmd and post-update-cmd scripts.

Eloquent Date Casting

It's now possible to customize the format of Eloquent date and datetime casting:

protected $casts = [
    'sign_up_date' => 'date:Y-m-d',
    'last_activity_at' => 'datetime:Y-m-d H:00',

Casting comes in handy when we want to serialize model attributes to a specific format.

Argon2i Password Hashing Algorithm Support

The Argon2i password hashing support will be supported by Laravel 5.6. Argon2 is a password-based key derivation function winner of the Password Hashing Competition in July 2015 and an evolution of the popular bcrypt and scrypt hashing algorithms.

There are two main versions of the Argon2 algorithm: Argon2i and Argon2d. Argon2i is the safest against side-channel attacks, while Argon2d provides the highest resistance against GPU cracking attacks. Note however that Argon2d is not suitable for password hashing and should not be used. You can control which hashing driver is used by default in the new config/hashing.php configuration file.

The old style of bcrypt will continue to be supported and will remain the default, but for those starting a new Laravel 5.6 project and are already running PHP 7.2+, I'd recommend using the Argon2i driver.

Collision Package for CLI Error Reporting

The new Laravel release now ships with the Collision package pre-installed as a dev composer dependency. Collision is an error handler package for PHP command line applications. With the package, we get beautiful error reporting when interacting with your Laravel applications through the command line. Below is a screenshot of the package in action:

Collision is built on top of the Whoops error handler, which we saw return in Laravel 5.5 and supports artisan and phpunit commands.

Bootstrap 4

Laravel 5.6 ships with Bootstrap 4 meaning, all front-end scaffolding such as the authentication boilerplate and example Vue component have been upgraded to Bootstrap 4.

API Resource Controller Generation

When generating a resource controller for an API in Laravel 5.6, we can pass in the --api flag to exclude the create and edit methods which only apply to resource controllers returning HTML:

php artisan make:controller API/SomethingController --api

Blade component aliases

Laravel 5.6 adds the ability to register alias directives for Blade components. Blade components were introduced in Laravel 5.4. If not familiar with the concept of Blade components, a blade component is a directive to include views inspired by "components" in JavaScript frameworks like Vue.

Let's say we have a component stored at resources/views/components/alert.blade.php. Normally, we access the component using:

    Here be dragons!

In Laravel 5.6, it's now possible to simplify the component syntax to a single directive with the new Blade::component function.

Back to our alert example:

Blade::component('components.alert', 'alert');

Once the component has been aliased, you may render it using its alias:

@alert('alert', ['type' => 'danger'])
    Here be dragons!

And if the component does not have additional slots, we can just use the component's name as a Blade directive:

    Here be dragons!

Single Server Scheduling

Scheduled tasks normally run on all servers for Laravel applications running on multiple servers. Let's say we have a scheduled task and our Laravel application has been deployed to two web servers and two worker servers. The task will execute on every server our application is running on. In this case, all four servers. Not cool!

It's now possible to limit a scheduled job to only execute on a single server in Laravel 5.6 using the onOneServer when defining the task:


Having specified the onOneServer method within our task definition, the first server to obtain the task will secure an atomic lock on the job to prevent other servers from running the same task at the same time.

Note, however, when using this feature, you will need to use the Redis or Memcached cache drivers. These drivers provide the atomicity needed to secure the locks that power this feature.

Dynamic Rate Limiting

In previous Laravel versions, when limiting the number of requests to a route group, we had to hardcode the value within the route group. Like so:

Route::middleware('auth:api', 'throttle:60,1')->group(function () {
    Route::get('/user', function () {

With the new release, we can just create a rate_limit attribute in the App\User model where we set the number of requests allowed in the given time limit.

We then pass the name of the attribute to the throttle middleware so that it is used to calculate the maximum request count:

Route::middleware('auth:api', 'throttle:rate_limit,1')->group(function () {
    Route::get('/user', function () {

Logging Improvements

This is the biggest feature in this new release. Logging has been moved from the config/app.php file to a new config/logging.php file.

It's also now possible to define stacks that send different log messages to different handlers. The stack driver allows you to combine multiple channels into a single log channel:

'channels' => [
    'stack' => [
        'driver' => 'stack',
        'channels' => ['syslog', 'slack'],

    'syslog' => [
        'driver' => 'syslog',
        'level' => 'debug',

    'slack' => [
        'driver' => 'slack',
        'url' => env('LOG_SLACK_WEBHOOK_URL'),
        'username' => 'Laravel Log',
        'emoji' => ':boom:',
        'level' => 'critical',

Looking at the above snippet, our stack channel aggregates two other channels via its channels option: syslog and slack. So, when logging messages, both of these channels will have the opportunity to log the message. Also, all debug messages will go to a system log while error logs go to slack. You can read more about this here.

Broadcast Channel Classes

Laravel 5.6 comes with a new artisan make:channel command:

php artisan make:channel OrderChannel

The generated channel will be placed inside the App/Broadcasting folder.

Having separate channel classes comes in handy especially when we have a Laravel application that consumes many different channels. There is a high probability the routes/channels.php file will get bulky. So, instead of using Closures to authorize channels, we can now leverage channel classes.

We then register this channel inside the routes/channels.php file:

use App\Broadcasting\OrderChannel;

Broadcast::channel('order.{order}', OrderChannel::class);

Authorization logic for the channel goes inside the join method for this channel as opposed to having the logic go inside the channel authorization closure.


As you can see, Laravel is becoming better with each new release. I only highlighted the most notable improvements in the framework; more thorough changelogs are available here. Leave your thoughts and suggestions in the comments section below and don’t forget to share with your fellow Laravel enthusiasts!

Like this article? Follow @@ninja_vickris on Twitter