I. PHP 7▲
La première grande nouveauté est la version minimale de PHP qui est désormais la 7 :
2.
3.
4.
"require"
:
{
"php"
:
">=7.0.0"
,
"laravel/framework"
:
"5.5.*"
,
...
Donc si vous voulez passer à cette version de Laravel, il faudra peut-être mettre à jour votre serveur !
Le principal intérêt se trouve au niveau des performances parce que cette version de PHP est vraiment plus rapide. Mais ce n'est pas le seul avantage, vous trouvez la liste des nouveautés dans le manuel PHP.
II. Les erreurs▲
II-A. Les pages d'erreurs▲
L'aspect des pages d'erreur par défaut (donc pour 404, 419, 500 et 503) a été relooké. C'est un changement purement cosmétique, mais ça fait du bien aux yeux :
Mais on peut évidemment créer son propre aspect comme dans les versions précédentes en créant un dossier resources/views/errors et en nommant les fichiers blade avec le numéro de l'erreur.
II-B. Les helpers throw_if et throw_unless▲
Deux nouveaux helpers apparaissent :
III. Retour des données de la validation▲
Laravel offre la puissante méthode validate pour valider les données :
La méthode jusque là ne retournait aucune valeur. Désormais elle va retourner les données de la requête. Du coup on pourra écrire :
Il faut évidemment que toutes les données passent par la validation, quitte à ne préciser aucune règle.
Personnellement j'utilise principalement des requêtes de formulaire et cette possibilité me laisse assez indifférent. D'autre part elle ne me paraît pas être d'un très grand intérêt.
IV. La commande migrate:fresh▲
Voici l'annonce officielle de cette commande.
Vous utilisez sans doute souvent la commande migrate:refresh. Elle permet de revenir à zéro pour repartir sur une migration toute fraîche. Mais pour que ça fonctionne, il faut prévoir des méthodes down dans les migrations pour définir le retour en arrière.
Avec la commande migrate:fresh plus besoin de méthode down, les tables sont purement et simplement supprimées et les migrations relancées. On peut lui adjoindre l'option -seed pour remplir les tables. Voilà une commande que je vais beaucoup utiliser !
V. La commande vendor:publish▲
Voilà une commande qui m'a souvent agacé parce que telle quelle, elle publie tout ce qu'elle trouve et ce n'est pas toujours judicieux !
Désormais lorsque vous utiliserez cette commande sans préciser de provider, vous aurez la liste de tous les providers et vous pourrez choisir celui que vous voulez publier !
Voici une animation bien faite pour cette commande :
VI. Les mails▲
VI-A. Les thèmes▲
La gestion des mails a bien progressé dans les dernières versions de Laravel, par exemple avec la possibilité d'utiliser le marquage Markdown. Cette fois on va pouvoir utiliser des thèmes. Dans la version 5.4, il y a un thème par défaut. On n'est pas obligé de l'utiliser, mais ça oblige à quelques changements : créer évidemment son propre CSS :
resources/views/vendor/mail/html/themes/mon-theme-a-moi.css
et aussi informer Laravel (config/mail.php) :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
/*
|--------------------------------------------------------------------------
| Markdown Mail Settings
|--------------------------------------------------------------------------
|
| If you are using Markdown based email rendering, you may configure your
| theme and component paths here, allowing you to customize the design
| of the emails. Or, you may simply stick with the Laravel defaults!
|
*/
'
markdown
'
=>
[
'
theme
'
=>
'
mon-theme-a-moi
'
,
'
paths
'
=>
[
resource_path('
views/vendor/mail
'
),
],
],
Ce n'est pas bien compliqué, mais la version 5.5 nous simplifie un peu plus la vie !
Il faut encore évidemment créer le fichier CSS, mais pour sa déclaration ça se passe directement dans la classe Mailable :
2.
3.
4.
5.
class MonMailAMoi extends
Mailable
{
protected
$theme
=
'mon-theme-a-moi'
;
...
}
VI-B. Le rendu dans le navigateur▲
Lorsqu'on développe un thème, ça dure évidemment un moment et on fait plein de réglages. On ne va pas chaque fois envoyer réellement un mail pour vérifier le rendu. Il existe des solutions, mais aucune de vraiment simple et directe.
Avec Laravel 5.5, on peut visualiser le mail directement dans le navigateur. Il suffit d'ajouter une route :
Et c'est tout !
Ça peut d'ailleurs donner d'autres idées d'utilisation…
VII. Le frontend▲
Le frontend a connu une évolution un peu houleuse au cours des versions. Avec Laravel 5.5 ça devient plus modulable et rien n'est imposé. On a toujours Bootstrap et Vue.js par défaut, mais on peut facilement (avec Artisan) changer pour React. Je suppose que ça va encore évoluer avec d'autres propositions.
VIII. Whoops▲
Ceux qui ont utilisé Laravel 4 doivent se souvenir de la fenêtre d'affichage des erreurs Whoops :
Eh bien, on va retrouver cette sympathique bibliothèque dans la version 5.5 !
IX. Chargement des packages▲
Taylor a présenté récemment une nouvelle fonctionnalité pour l'installation des packages. On est tous habitués à effectuer toujours les mêmes opérations pour installer un package :
- utilisation de composer ;
- déclaration du service providers dans la configuration ;
- déclaration éventuelle de la façade dans la configuration.
Avec la version 5.5, on pourra se contenter de composer, le reste sera reconnu automatiquement si le package est configuré pour ça !
X. Conclusion▲
Laravel 5.5 ne nous apporte pas des changements très importants, mais se présente plutôt comme l'aboutissement de la série 5.
XI. Remerciements▲
Nous remercions Maurice Chavelli qui nous a autorisés à publier ce tutoriel.
Nous remercions également Winjerome pour la mise au gabarit et Claude Leloup pour la relecture orthographique.