PHP 7.2 est sorti officiellement le 30 Novembre. Cette version a de nouvelles fonctionnalités, fonctions et améliorations qui nous permettront d’écrire un meilleur code. Dans cet article, je vais vous présenter quelques-unes des fonctionnalités les plus intéressantes du langage PHP 7.2.

Améliorations du coeur

Déclarations de type d’argument

Depuis PHP 5, nous sommes autorisés à spécifier dans la déclaration d’une fonction le type d’argument que l’on s’attend à ce qui soit passé. Si la valeur donnée est d’un type incorrect, PHP lance une erreur..

Les déclarations de type d’argument (aussi connues sous le nom de type hints) spécifient le type d’une variable qui devrait être transmise à une fonction ou à une méthode de classe.

Voici un exemple:

class MyClass {
	public $var = 'Hello World';
}

$myclass = new MyClass;

function test(MyClass $myclass){
	return $myclass->var;
}

echo test($myclass);

Dans ce code, la fonction test  attend une instance de MyClass. Un type de données incorrect entraînera l’erreur fatale suivante :

Fatal error: Uncaught TypeError: Argument 1 passed to test() must be an instance of MyClass, string given, called in /app/index.php on line 12 and defined in /app/index.php:8

Depuis PHP 7.2, les type hints peut être utilisé avec le type de données de l’objet, et cette amélioration permet de déclarer un objet générique comme argument d’une fonction ou d’une méthode. Voici un exemple :

class MyClass {
	public $var = '';
}

class FirstChild extends MyClass {
	public $var = 'My name is Jim';
}
class SecondChild extends MyClass {
	public $var = 'My name is John';
}

$firstchild = new FirstChild;
$secondchild = new SecondChild;

function test(object $arg) {
	return $arg->var;
}

echo test($firstchild);

echo test($secondchild);

Dans cet exemple, nous avons appelé la fonction test deux fois, en passant un objet différent à chaque appel. Cela n’était pas possible dans les versions précédentes de PHP..

commandes Docker
Test des types hints avec PHP 7.0 et PHP 7.2 dans Docker

Déclarations return type de l’objet

Si les déclarations de type d’argument spécifient le type attendu pour les arguments d’une fonction, return type declarations spécifie le type attendu de la valeur retournée.

Les déclarationns Return type spécifient le type d’une variable que l’on attend à ce qu’une fonction renvoie.

Grâce à PHP 7.2 nous pouvons utiliser les déclarations return type pour le type de données de l’object. Voici un exemple :

class MyClass {
	public $var = 'Hello World';
}

$myclass = new MyClass;

function test(MyClass $arg) : object {
	return $arg;
}

echo test($myclass)->var;

Les versions précédentes de PHP affichent l’erreur fatale suivante:

Fatal error: Uncaught TypeError: Return value of test() must be an instance of object, instance of MyClass returned in /app/index.php:10

Bien sûr, dans PHP 7.2 ce code affiche ‘Hello World’.

Type de paramètre Widening

PHP ne permet actuellement aucune variance des types de paramètres entre les classes enfant et leurs classes parent ou interfaces. Qu’est-ce que cela veut dire ?
Considérez le code suivant:

<?php
class MyClass {
	public function myFunction(array $myarray) { /* ... */ }
}

class MyChildClass extends MyClass {
	public function myFunction($myarray) { /* ... */ }
}

Ici, nous avons omis le type de paramètre dans la sous-classe. En PHP 7.0, ce code produit l’avertissement suivant :

Warning: Declaration of MyChildClass::myFunction($myarray) should be compatible with MyClass::myFunction(array $myarray) in %s on line 8

Depuis PHP 7.2, nous pouvons omettre un type dans une sous-classe sans casser le code. Cette proposition nous permettra de mettre à niveau les classes à utiliser le type hints dans les bibliothèques sans avoir à mettre à jour toutes les sous-classes..

Virgules de fin dans la syntaxe de liste

Une virgule de fin après le dernier elément d’un tableau est une syntaxe valide dans PHP, et c’est parfois conseillé pour ajouter facilement des éléments et éviter les « parse errors » dûes à une virgule manquante. Depuis PHP 7.2 nous pouvons utiliser des virgules de fin dans les namespaces groupés.

Voir Trailing Commas In List Syntax pour une vue d’ensemble de ce RFC et quelques exemples de code.

Améliorations de la sécurité

Argon2 dans le hachage du mot de passe

Argon2 est un puissant algorithme de hachage qui a été sélectionné en tant que gagnant du concours 2015 Password Hashing Competition, et PHP 7.2 nous le propose en tant qu’alternative sécurisée à l’algorithme Bcrypt.
La nouvelle version de PHP introduit la constante PASSWORD_ARGON2I, cela peutmaintenant être utilisé dans les fonctions password_* :

password_hash('password', PASSWORD_ARGON2I);

Contrairement à Bcrypt, qui ne prend qu’un seul facteur de coût, Argon2 prend trois facteurs de coût qui se distinguent comme suit :

  • Un coût de la mémoire qui définit le nombre de KiB à consommer pendant le hachage (les valeurs par défaut sont 1<<10, ou 1024 KiB, ou 1 MiB).
  • Un coût en temps qui définit le nombre d’itérations de l’algorithme de hachage (2 par défaut).
  • Un facteur de parallélisme, qui définit le nombre de threads parallèles qui seront utilisés pendant le hachage (2 par défaut).

Trois nouvelles constantes définissent les facteurs de coûts par défaut :

  • PASSWORD_ARGON2_DEFAULT_MEMORY_COST
  • PASSWORD_ARGON2_DEFAULT_TIME_COST
  • PASSWORD_ARGON2_DEFAULT_THREADS

Voici un exemple :

$options = ['memory_cost' => 1< 4, 'threads' => 2];
password_hash('password', PASSWORD_ARGON2I, $options);

Voir Argon2 Password Hash pour plus d’informations.

Libsodium dans le coeur de PHP

A partir de la version 7.2, PHP inclut la bibliothèque Sodium dans le coeur. Libsodium est une bibliothèque multiplateforme et multilingue pour le cryptage, le décryptage, les signatures, le hachage de mots de passe et plus encore.
La bibliothèque était auparavant disponible via PECL.
Pour une liste documentée des fonctions Libsodium, reportez-vous à la bibliothèque Quick Start Guide.
Voir aussi PHP 7.2: The First Programming Language to Add Modern Cryptography to its Standard Library.

Dépréciations

Voici une liste des fonctions et fonctionnalités obsolètes dans PHP 7.2 et qui seront supprimées avec l’arrivée de PHP 8.0 :

La fonction __autoload a été remplacée par la fonction spl_autoload_register dans PHP 5.1. Maintenant, un avis de dépréciation sera lancé lorsqu’elle est rencontrée lors de la compilation..

La variable $php_errormsg est créé dans le champ d’application local lorsqu’une erreur non fatale est lancée. Depuis PHP 7.2 error_get_last et error_clear_last doivent plutôt être utilisées.

create_function() permet la création d’une fonction avec un nom de fonction généré, une liste d’arguments et le code du corps fourni comme arguments. En raison de problèmes de sécurité et de mauvaises performances, il a été marqué comme obsolète et l’utilisation d’enclosures est encouragée à la place.

Le paramètre ini mbstring.func_overload réglé sur une valeur non nulle a été marqué comme obsolète.

(unset) cast est une expression qui renvoie toujours null et est considérée comme inutile.

parse_str() analyse une chaîne de requête dans un tableau si le second argument est fourni, ou dans la table des symboles locaux si elle n’est pas utilisée. Comme le réglage dynamique des variables dans la portée de la fonction est déconseillé pour des raisons de sécurité, l’utilisation de parse_str() sans le second argument affichera un avis de dépréciation.

gmp_random() is considered to be platform dependent and will be deprecated. Use gmp_random_bits() and gmp_random_rage() instead.

each() est utilisé pour itérer sur un tableau, un peu comme foreach(), mais foreach() est préférable pour plusieurs raisons, dont le fait d’être 10 fois plus rapide. Maintenant, une dépréciation sera affichée lors du premier appel dans une boucle.

La fonction assert() vérifie l’affirmation donnée et prend les mesures appropriées si le résultat est FALSE. L’utilisation de la fonction assert() avec l’argument string est maintenant obsolète car elle ouvre une vulnérabilité RCE. L’option ini zend.assertion peut être utilisée pour empêcher l’évaluation des expressions d’assertion.

$errcontext est un tableau contenant les variables locales existantes au moment où une erreur est générée. Il est passé comme dernier argument aux gestionnaires d’erreur définis avec la fonction set_error_handler().

Que signifie PHP 7.2 pour les utilisateurs WordPress ?

Selon la page officielle de WordPress Stats, au moment d’écrire ces lignes, seulement 19,8% des utilisateurs de WordPress ont mis à jour vers PHP 7. Et seulement 5% utilisent PHP 7.1. Vous pouvez voir qu’une grande majorité d’utilisateurs, plus de 40%, qui fonctionnent toujours en PHP 5.6. Ce qui est encore plus effrayant, c’est que plus de 39% des utilisateurs utilisent des versions PHP non supportées. En décembre 2016, WordPress.org a fait passer sa recommandation officielle pour les utilisateurs de PHP 5.6 à PHP 7 ou plus.

stats WordPress PHP 7.1
Stats WordPress PHP 7.1

Les chiffres ci-dessus sont particulièrement décourageants du point de vue de la performance, car PHP 7 s’est montré beaucoup plus rapide. Voici quelques statistiques :

  • Les tests PHP officiels montrent que PHP 7 permet au système d’exécuter deux fois plus de requêtes par seconde par rapport à PHP 5.6, à presque la moitié de latence.
  • Christian Vigh a également publié une comparaison des performances de PHP dans laquelle il a trouvé que PHP 5.2 était 400% plus lent que PHP 7.

Nous avons également effectué nos propres tests de performance en 2018 avec PHP 5.6 vs PHP 7 vs HHVM. Et de manière similaire aux tests ci-dessus, nous avons vu que PHP 7.2 pouvait exécuter presque trois fois plus de transactions (requêtes) par seconde que PHP 5.6.

Tests WordPress
Tests WordPress
  • Résultats du test WordPress 4.9.4 PHP 5.6 : 49.18 req/sec
  • Résultats du test WordPress 4.9.4 PHP 7.0 : 133.55 req/sec
  • Résultats du test WordPress 4.9.4 PHP 7.1 : 134.24 req/sec
  • Résultats du test WordPress 4.9.4 PHP 7.2 148.80 req/sec ?
  • Résultats du test WordPress 4.9.4 : 144.76 req/sec

Beaucoup sont lents à mettre à jour simplement à cause du temps nécessaire pour tester toutes leurs extensions et thèmes tiers afin de s’assurer qu’ils fonctionnent correctement. Mais bien souvent, cela revient à dire qu’ils ne l’ont pas encore fait. Vous n’êtes pas sûr de la version de PHP que vous utilisez ? L’un des moyens les plus faciles à vérifier est d’utiliser un outil comme Pingdom ou Google Chrome Devtools. Le premier header de requête HTTP vous montrera habituellement la version.

Vérifier la version de PHP
Vérifier la version de PHP

This relies on the host not modifying the X-Powered-By header value. If they do, you might not see your PHP version, in which case you would need to upload a file via FTP. Or you can always reach out to your host and ask.

Ceci repose sur le fait que l’hébergeur ne modifie pas la valeur de l’en-tête X-Powered-By. Si c’est le cas, vous ne verrez peut-être pas votre version PHP, auquel cas vous devrez télécharger un fichier par FTP. Ou vous pouvez toujours contacter votre hébergeur et lui demander.

Mettre à jour vers PHP 7.2

PHP 7.2 n’est pas encore tout à fait sorti, mais une fois qu’il le sera, vous pourrez commencer à le tester. Vous pouvez tester votre site WordPress en local et ou vérifier vos scripts dans un environnement comme Docker, qui vous permet de tester différentes versions de PHP à partir de la ligne de commande.

Ou vous pouvez utiliser un environnement de développement, car cela ressemblera davantage à un site de production en direct. Kinsta a rendu PHP 7.2 disponible pour tous les clients le 4 décembre. Vous pouvez facilement créer un environnement de développement en un seul clic.

Test PHP 7.2 dans un environnement de développement
Test PHP 7.2 dans un environnement de développement

Il suffit d’un clic pour changer le moteur PHP du site en développement sous « Outils » et vous pouvez commencer à tester la compatibilité de vos extensions et thèmes tiers. Une fois que vous avez confirmé que tout fonctionne, vous pouvez soit changer votre site de production en PHP 7.2, soit passer votre site de développement en ligne sur la production.

Changer pour PHP 7.2
Changer pour PHP 7.2

Conclusions

Êtes-vous prêt à passer à PHP 7.2 ? Espérons que maintenant, vous avez au moins fait la transition vers PHP 7. Si vous ne l’avez pas encore fait, c’est le bon moment pour commencer à tester. Alors, mettez à jour vos scripts, vérifiez votre code et faites-nous part de vos premières impressions sur PHP 7.2.

Carlo Daniele Kinsta

Carlo is a passionate lover of webdesign and front-end development. He has been playing with WordPress for more than 20 years, also in collaboration with Italian and European universities and educational institutions. He has written hundreds of articles and guides about WordPress, published both on Italian and international websites, as well as on printed magazines. You can find him on LinkedIn.