It’s that time of year again, and there’s a new version of Laravel out right now! The focus of this release seems to have been code cleanup and ease of use. Some highlights are:
Laravel 5.6 now requires PHP 7.1.3 or higher. This is due to the migration to Symfony 4 components under the hood. The following table summarizes the required/supported versions of Laravel’s Symfony dependencies and its supported versions of PHPUnit.
Laravel 5.1 LTS Laravel 5.4 Laravel 5.5 LTS Laravel 5.6 PHP 5.5.9 - 7.2 5.6.4 - 7.2 7.0.0 - 7.2+* 7.1.3 - 7.2+* Symfony 2.7 LTS 3.2 - 3.4 LTS 3.3 - 3.4 LTS 4.x PHPUnit 4/5** 5 6 7
* Laravel 5.5 and 5.6 support PHP 7.2.x, but it is likely that when PHP 7.3 is released, any changes needed to Laravel 5.5 and 5.6 to make them work will be applied by the Laravel core team. PHP 7.2 was released at the end of November 2017, and PHP 7.3 is expected at a similar time in 2018.
** Laravel 5.1 ships with PHPUnit 4; however, it is possible to upgrade to PHPUnit 5 if support for PHP 5.5 is not needed.
Laravel 5.6’s logging system has been largely rewritten to use Monolog handlers, making it easy to build logging “stacks” that send log messages to multiple handlers.
In Laravel 5.5, the
Illuminate\Log\Writer class was the entry point for logging and implemented both the
Illuminate\Contracts\Logging\Log interfaces. The Log facade proxies calls to the object bound to the
Psr\Log\LoggerInterface, which by default, would be that writer class.
In Laravel 5.6, the Laravel Log interface and
Writer class have been removed, replaced by the
Illuminate\Log\LogManager class, which implements
Psr\Log\LoggerInterface. Internally, the
LogManager constructs an instance of the new
Illuminate\Log\Logger class to wrap an inner logger. This is done so that Laravel logging events can be fired. An inner logger is an instance of
Monolog\Logger. Such loggers are what can be returned when you register a custom logger.
When upgrading, keep in mind there is a new configuration file
config/logging.php, and the
log_level config should be removed from your
config/app.php file. In terms of logging and exception handling, there are no changes you should notice - just keeping using the
Log facade and it’ll work in exactly the same way. Learn more about Laravel 5.6’s logging system in the documentation.
Laravel 5.6 now supports using the new Argon2i hashing algorithm if you are using PHP 7.2. Argon2i is a secure, memory hard, side-channel hardened hash function.
You may ask, why should I switch to Argon2i hashing when Bycrypt is a long-standing industry standard? Bcrypt is a password hashing function. The difference to cryptographic hashes like SHA-1 is that it adds a time cost to hashing so if someone steals your password hashes, it’s going to be very expensive to work out the passwords.
Unfortunately, there is an arms race with the attackers, and high time cost is no longer good enough when attackers have GPU farms. The solution is to introduce a memory cost as well as a time cost, which makes things much more expensive for an attacker to parallelize.
There are few internal changes, ultimately resulting in a new hashing configuration file. As of today, the “bcrypt” hashing driver remains the default, but “argon” may be selected if desired.
In Laravel 5.5, if your application is running on multiple servers, scheduling a job will result in the job running on every server. While this is often what you would want, and indeed would expect, it is not always what is required, for example when generating a monthly report.
Now, in Laravel 5.6, it is possible to limit a job to running on only one server using the
onOneServer method when defining the scheduled task. This works by the scheduler acquiring a lock on the job and then marking it as done so the other schedulers know not to run it.
You can learn more about this in the documentation, but it looks to be as simple as:
$schedule->command('report:generate') ->fridays() ->at('17:00') ->onOneServer();
Laravel 5.6 gets a fancy upgrade to its exception rendering in the console. While Laravel 5.5 was using Symfony’s exception rendering, Laravel 5.6 now uses the nunomaduro/collision package to render console exceptions.
Editors note: The new format looks very similar to how Bugsnag shows you errors in production, and we already updated our error reporting library to fully support Laravel 5.6
This package is built on top of Whoops, which Laravel already uses to render its HTTP exception pages out of the box in development mode. This means you get a much clearer idea of what went wrong, with the code around the file presented to you, as well as the stack trace.
Hopefully, upgrading to Laravel 5.6 will be painless, but there may be a few “gotchas” along the way. Luckily, there is an upgrading guide available on the official documentation website. Here’s a brief summary of some of the important changes to keep in mind:
Bootstrap 4 has finally landed, and Laravel 5.6 is ready. By default, the pagination component will now generate Bootstrap 4 compatible links by default. If Bootstrap 3 style is required, put the following in your app service provider:
The built-in HTML escaping function “e” shall now double encode by default. To turn this off, pass “false” as the second argument to the call to “e”. Similarly, in blade templates, the auto-escaping tags will now double encode. To turn this off, you can put the following in your app service provider:
Previously, Swift Messages customization callbacks registered using
withSwiftMessage were called after the content was already encoded. In Laravel 5.6, these callbacks are now called before the content is encoded and added.
In Laravel 5.6, the validate method of the ValidatesWhenResolved interface has been renamed to validateResolved in order to avoid conflicts with request validation.
Bugsnag helps you proactively monitor and improve your software quality. Use Bugsnag to debug your applications and track the health of releases. Our Laravel library is compatible with version 5.6 of Laravel.