A partir du 6 décembre 2018, la dernière et plus grande version, PHP 7.3 est arrivée ! Avec lui viennent de nouvelles fonctionnalités utiles, des fonctionnalités, des suppressions, un bon nombre de corrections de bogues et un boost de performances. PHP 7.3 aussi maintenant disponible pour tous les clients Kinsta dans le tableau de bord MyKinsta. 🤘

Mise à jour : PHP 8.1 (version officielle) est maintenant disponible pour tous les clients Kinsta. PHP 7.3 n’est plus supporté par Kinsta. Veuillez noter que nous supportons les versions de PHP 8.1, 8.2 et 8.3.

Dans cet article, nous vous donnerons un aperçu des caractéristiques et des changements que nous jugeons personnellement les plus pertinents. Mais vous pouvez toujours consulter la liste complète des fonctionnalités, changements et corrections de bugs dans les notes de mise à jour de PHP 7.3 et les demandes de commentaires sur PHP 7.3.

Quoi de neuf dans PHP 7.3?

Dans cet article, nous couvrons les changements suivants de PHP 7.3 :

Syntaxes flexibles Heredoc et Nowdoc

C’est probablement l’une des améliorations les plus pertinentes de PHP 7.3, et nous pensons qu’elle mérite un peu plus d’attention. Donc, avant de plonger dans les changements de PHP 7.3 heredoc/nowdoc, nous allons vous donner un bref aperçu de cette fonctionnalité de base utile. Si vous êtes déjà en confiance avec nowdoc et heredoc, n’hésitez pas à passer aux changements de PHP 7.3.

Vue d’ensemble des syntaxes heredoc et nowdoc

La syntaxe heredoc permet d’ajouter une grande quantité de texte sans avoir besoin d’échapper avec des choses comme les guillemets doubles. Un hérédoc commence par <<< suivi d’un marqueur, et se termine par le même marqueur suivi d’un point-virgule. En voici un exemple :

print <<<EOT
Le texte heredoc se comporte comme une chaîne à guillemets doubles, sans les guillemets doubles.
EOT;

Un nowdoc se comporte comme un hérédoc, à quelques exceptions près :

  • L’identificateur est entre guillemets simples (<<<'EOT')
  • Aucune analyse n’est effectuée à l’intérieur d’un nowdoc

Voici un exemple de nowdoc :

print <<<'EOT'
Nowdocs sont à des chaînes à simple guillemet ce que heredocs sont à des chaînes à double guillemet.
EOT;

Heredocs et nowdocs partagent les mêmes règles régissant l’utilisation du marqueur de fermeture :

  1. Le marqueur de fermeture doit commencer dans la première colonne de la ligne.
  2. Le marqueur doit suivre les mêmes règles de nommage que n’importe quelle autre étiquette en PHP : il ne doit contenir que des caractères alphanumériques et des traits de soulignement, et doit commencer par un caractère non numérique ou un trait souligné.

Le manuel PHP avertit :

Il est très important de noter que la ligne avec l’identificateur de fermeture ne doit contenir aucun autre caractère, sauf un point-virgule (;). Cela signifie en particulier que l’identificateur ne doit pas être indenté et qu’il ne doit pas y avoir d’espaces ou de tabulations avant ou après le point-virgule. Il est également important de comprendre que le premier caractère avant l’identificateur de fermeture doit être une nouvelle ligne telle que définie par le système d’exploitation local. C’est un problème sur les systèmes UNIX, y compris MacOS. Le délimiteur de fermeture doit également être suivi d’une nouvelle ligne.

Syntaxe PHP 7.2 invalide :

class foo {
    public $bar = <<<EOT
    bar
    EOT;
}
// L'identifiant ne doit pas être indenté

Syntaxe PHP 7.2 valide :

class foo {
    public $bar = <<<EOT
bar
EOT;
}

Pour être bref, en PHP 7.2 :

  • Le repère de fermeture ne doit pas être en retrait
  • La ligne avec le marqueur de fermeture ne doit pas contenir de caractères tels que des espaces ou des tabulations.
  • Le premier caractère avant le marqueur de fermeture doit être une nouvelle ligne.
  • La marque de fermeture doit être suivie d’une nouvelle ligne

Il est assez clair que les syntaxes heredoc et nowdoc sont assez restrictives, mais PHP 7.3 peut changer cela un peu avec les améliorations suivantes

1. Permettre d’indenter le marqueur de fermeture et de supprimer l’espace de l’en-tête

Avec PHP 7.3, nous sommes autorisés à indenter le marqueur de fermeture, et nous pouvons écrire en toute sécurité le code suivant :

class foo {
    public $bar = <<<EOT
        bar
    EOT;
}

L’indentation du marqueur de fermeture définit la quantité d’espaces blancs (ou de tabulations) qui seront retirés de chaque ligne du corps. Mais attention : le marqueur de fermeture ne doit jamais être indenté plus loin que n’importe quelle autre ligne du corps.

Voir le code ci-dessous :

class foo {
    public $bar = <<<EOT
    bar
        EOT;
}

Le code ci-dessus émettrait l’erreur suivante :

Parse error: Invalid body indentation level (expecting an indentation at least ...) in %s on line %d

Les tabulations et les espaces nous permettent d’indenter le corps du hérédoc/nowdoc au même niveau que le code autour, et sans espaces inutiles devant chaque ligne du corps.

Nous pouvons utiliser à la fois des tabulations et des espaces pour l’indentation, mais nous ne sommes pas autorisés à les utiliser entremêlés. Cela signifie que nous devons utiliser les mêmes caractères d’indentation pour le marqueur de fermeture et toutes les lignes du corps. En cas de caractères d’indentation différents, on s’attendrait à un type différent d’erreur (indentation invalide).

2. Suppression de l’exigence de nouvelle ligne de suivi du marqueur de clôture

Actuellement, une nouvelle ligne doit suivre le marqueur pour terminer le heredoc/nowdoc. PHP 7.3 changera cela et nous permettra de terminer le heredoc/nowdoc sur la même ligne. Voici un exemple tiré du RFC :

Syntaxe PHP 7.2 valide :

$values = [<<<END
a
b
c
END
, 'd e f'];

Syntaxe PHP 7.3 valide :

$values = [<<<END
a
b
c
END, 'd e f'];

Quoi qu’il en soit, soyez prudent lors du choix du nom de votre marqueur car « occasionnellement » vous pouvez vous attendre à une erreur s’il correspond à un mot que vous avez utilisé dans le corps du heredoc/nowdoc (voir RFC et GitHub pour en savoir plus à ce sujet).

Les deux propositions ont été adoptées avec plus de 2/3 des voix.

PHP 7.3 RFC

Ressources supplémentaires

Autoriser une virgule flottante dans les appels de fonction

Les virgules flottantes (ou « virgules finales ») sont des virgules ajoutées à une liste d’éléments, de paramètres ou de propriétés et elles sont utiles dans les contextes où de nouvelles valeurs sont ajoutées fréquemment car elles empêchent les erreurs dues à une virgule manquante. En PHP, les virgules sont permises dans les tableaux, et à partir de PHP 7.2 elles sont permises dans les espaces de noms groupés.

A partir de PHP 7.3, ces virgules seront autorisées dans les déclarations de fonctions. Les fonctions Variadic fournissent un exemple de contexte où ces virgules sont extrêmement utiles :

foo(
    $bar,
    $baz,
);

Nous pouvons utiliser une virgule de fin quand nous créons un tableau avec compact(), afin de retourner une chaîne formatée avec sprintf(), ou quand nous fusionnons un tableau :

$newArray = array_merge(
    $arrayOne,
    $arrayTwo,
    ['foo', 'bar'],
);

De plus, des virgules seront utiles pour le débogage :

var_dump(
    $foo,
    $bar,
    $baz,
);

Et ils sont puissants avec unset() et isset():

unset(
    $foo,
    $bar,
    $baz,
);

isset(
    $foo,
    $bar,
    $baz,
);

Les virgules traînantes seront également permises dans les appels de méthode et les pièces jointes.

Remarque : Ce changement n’affectera que les appels de fonction. La syntaxe de la déclaration de fonction ne changera pas. De plus, les virgules isolées, les guillemets multiples et les virgules d’en- tête ne seront pas autorisés.

D’autres exemples peuvent être trouvés sur la page RFC. Ce RFC a été adopté par 30 voix contre 10.

PHP 7.3 RFC

JSON_THROW_ON_ERROR

L’une des fonctionnalités les plus appréciées de PHP 7.3 offre une nouvelle façon de gérer les erreurs JSON. Ce n’est pas une fonctionnalité de base, mais un ajout à l’extension JSON qui changera le comportement d’erreur de json_decode() et json_encode().

Actuellement, json_decode() retourne null en cas d’erreur, mais null peut aussi être un résultat valide. Cela pourrait prêter à confusion, car

Il n’est possible de savoir si une erreur s’est produite qu’en appelant json_last_error() ou json_last_error_msg(), qui retournent l’état d’erreur global sous forme lisible par machine et lisible par l’homme respectivement. – PHP RFC

json_encode() retourne FALSE en cas d’erreur.

C’est plus clair parce qu’il y a une valeur d’erreur spécifique. Quoi qu’il en soit, les deux fonctions n’arrêtent pas l’exécution du programme en cas d’erreur, ni ne lancent aucun avertissement.

Ceci étant dit, voici la proposition pour PHP 7.3 :

Ce RFC propose plutôt d’ajouter une nouvelle valeur d’option pour json_decode() et json_encode(), JSON_THROW_ON_ERROR. Lorsque cet avertissement est passé, le comportement d’erreur de ces fonctions est modifié. L’état d’erreur global n’est pas touché, et si une erreur se produit, ces fonctions lancent à la place une JsonException avec le message et le code mis à tout ce que json_last_error() et json_last_error_msg() seraient autrement respectivement.

Voici un exemple montrant une façon simple de lancer une erreur JSON :

try {
    json_decode("{", false, 512, JSON_THROW_ON_ERROR);
}
catch (\JsonException $exception) {
    echo $exception->getMessage(); // echoes "Syntax error"
}

Lancer une exception en cas d’erreur donneront plusieurs avantages que vous trouverez listés sur le RFC.

Note : un paramètre de profondeur invalide passé à json_decode() émet un avertissement et retourne NULL. Ce comportement ne sera pas affecté par JSON_THROW_ON_ERROR. De même, les erreurs d’analyse des paramètres ne sont pas affectées par JSON_THROW_ON_ERROR et continuent à produire des avertissements.

Cette proposition a été adoptée par 23 voix contre 0.

PHP 7.3 RFC

Ressources supplémentaires

list() Affectation de référence

Que signifie l’affectation de référence ?

Considérez la ligne suivante :

$b = &$a;

Ici $b prend la valeur $a, mais cette valeur n’est pas copiée de $a à $b. En PHP, nous pouvons assigner une valeur par référence, ce qui signifie que deux variables peuvent pointer vers les mêmes données, et chaque changement de variable affecte les données d’origine. Voici un exemple tiré du manuel PHP :

<?php
$a = 3;
$b = &$a; // $b est une référence pour $a

print "$a\n"; // affiche 3
print "$b\n"; // affiche 3

Maintenant, changeons la valeur  de $a:

$a = 4; // change $a

print "$a\n"; // affiche 4
print "$b\n"; // affiche 4 aussi, puisque $b est une référence pour $a, qui a été changé

Qu’est-ce que la construction de list() et comment change-t-elle avec PHP 7.3

Le langage de construction de list() peut être utilisé pour « assigner des variables comme si elles étaient dans un tableau », mais avec list()

nous ne sommes pas actuellement autorisés à assigner des valeurs de variables par référence.

PHP 7.3 devrait changer cela en nous permettant d’assigner des variables par référence aussi avec la construction de list() comme montré dans l’exemple suivant :

$array = [1, 2];
list($a, &$b) = $array;

Ce qui est la même chose que :

$array = [1, 2];
$a = $array[0];
$b =& $array[1];

L’avantage de cette proposition est que nous pouvons maintenant assigner plusieurs variables par référence, ce qui n’était pas permis actuellement. D’autres exemples sont disponibles sur le RFC. Cette proposition a été adoptée par 17 voix contre 7.

PHP 7.3 RFC

Ressources supplémentaires

Fonction is_countable

Une autre fonctionnalité utile fournie avec PHP 7.3 est la fonction is_countable(). Jusqu’à PHP 7.2, nous obtenons une erreur lorsque nous essayons de count() quelque chose qui n’est pas comptable. Pour cette raison, afin d’éviter un avertissement, nous sommes obligés d’ajouter le code suivant :

if (is_array($foo) || $foo instanceof Countable) {
    // $foo is countable
}

Ce RFC propose la fonction is_countable(), qui retourne true si la variable donnée est un tableau ou une variable comptable, false sinon. Ainsi, le code ci-dessus pourrait être modifié comme suit :

if (is_countable($foo)) {
    // $foo is countable
}

Cette proposition a été adoptée par 25 voix contre 0.

PHP 7.3 RFC

Ressources supplémentaires

array_key_first(), array_key_last()

Actuellement, nous pouvons récupérer la première et la dernière clé d’un tableau en utilisant les fonctions reset(), end()et key(). Malheureusement, avec ces fonctions, il n’est pas possible de rassembler le premier ou le dernier index d’un tableau sans changer son état interne. D’autres options réduisent généralement la lisibilité et les performances du code, et cette proposition changerait ce scénario en ajoutant deux nouvelles fonctions au noyau de PHP :

  • array_key_first()
  • array_key_last()

Depuis PHP 7.3, array_key_first() et array_key_last() permettent de récupérer la première et la dernière clé d’un tableau donné sans affecter le pointeur interne du tableau. Ces nouvelles fonctions nous permettraient d’écrire du code moins complexe et dans certains cas d’éviter des erreurs. Voir le RFC pour plus d’informations et plusieurs exemples.

array_key_first() et array_key_last() ont été approuvés avec 18 à 14 votes.

Note : le RFC original proposait deux fonctions supplémentaires, array_value_first() et array_value_last(), qui ont été votées dans un sondage différent, mais n’ont pas été approuvées et ne feront pas partie du noyau de PHP.

PHP 7.3 RFC

Ressources supplémentaires

Améliorations apportées à Argon2 Password Hash

Argon2 est un algorithme de hachage implémenté en PHP 7.2 comme alternative à l’algorithme Bcrypt. PHP 7.2 a introduit la constante PASSWORD_ARGON2I, disponible pour être utilisée dans les fonctions password_* :

password_hash('password', PASSWORD_ARGON2I);

Depuis sa première implémentation, une nouvelle variante d’Argon2 a été ajoutée, ainsi, au moment d’écrire ces lignes, Argon2 existe en trois variantes :

  • Argon2d maximise la résistance aux attaques de cracking GPU. Il est plus rapide et utilise un accès mémoire en fonction des données.
  • Argon2i utilise un accès mémoire indépendant des données, ce qui est préférable pour le hachage des mots de passe. Il est plus lent car il fait plus de passes sur la mémoire pour se protéger des attaques tadeoff.
  • Argon2id est une version hybride qui combine l’approche Argon2i pour la première mémoire de passage et l’approche Argon2d pour les passages suivants.

Argon2id est recommandé sur Internet, sauf lorsqu’il y a de bonnes raisons de préférer spécifiquement une autre variante.

Le nouveau RFC propose l’implémentation d’Argon2id dans les fonctions password_* avec la nouvelle constante PASSWORD_ARGON2ID :

password_hash('password', PASSWORD_ARGON2ID);

L’implémentation est identique à l’implémentation Argon2i, et acceptera les mêmes facteurs de coût :

  • Un coût de 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 (par défaut : 2)
  • Un facteur de parallélisme, qui définit le nombre de threads parallèles qui seront utilisés pendant le hachage (valeur par défaut : 2).

Voir le code suivant :

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

Plus d’informations et d’exemples sur le RFC.

PHP 7.3 RFC

Ressources supplémentaires

Dépréciations

Les fonctions/fonctionnalités suivantes seront obsolètes avec PHP 7.3 et supprimées au plus tard avec PHP 8.0.

Dépréciation et suppression de image2wbmp()

La fonction image2wbmp() édite ou enregistre une version WBMP d’une image donnée. Cette fonction prend trois arguments : une ressource image, un nom de fichier (le chemin vers le fichier sauvegardé), et une couleur d’avant-plan.

À partir de PHP 5.0, elle est identique à imagewbmp(), donc ce RFC propose de la déprécier et de la supprimer, ainsi dans PHP 7.3 chaque appel à image2wbmp() émet un avertissement de dépréciation. Après le retrait, chaque appel lancera une erreur fatale.

PHP 7.3 RFC

Dépréciation et suppression des constantes insensibles à la casse

PHP supporte actuellement les constantes sensibles à la casse et insensibles à la casse. Quoi qu’il en soit, les constantes insensibles à la casse sont prises en charge mais sont considérées comme sujettes à des incohérences dans les fonctionnalités et comme étant complexes à utiliser :

  • les constantes de classe sont toujours sensibles à la casse
  • les constantes globales déclarées avec const sont toujours sensibles à la casse
  • les constantes définies avec define() sont sensibles à la casse par défaut

De plus, la référence du langage PHP stipule explicitement :

Une constante est sensible à la casse par défaut. Par convention, les identificateurs constants sont toujours en majuscules.

Cela étant dit, ce RFC propose les changements suivants :

  • Déprécier l’appel define() avec le troisième paramètre mis à true – PHP 7.3
  • Déprécier l’accès aux constantes insensibles à la casse avec une enveloppe différente de la déclaration (à l’exception de true, false et null) – PHP 7.3
  • Supprimer la possibilité de déclarer des constantes insensibles à la casse – PHP 8.0
  • Convertir les constantes true, false et null de constantes spéciales en mots-clés réservés – PHP 8.0

PHP 7.3 RFC

Dépréciation et suppression des constantes insensibles à la casse.

Dépréciations supplémentaires pour PHP 7.3

Voici une liste rapide des fonctionnalités obsolètes de PHP 7.3. Ce n’est pas exhaustif, ce ne sont que les propositions de dépréciation que je considère personnellement les plus pertinentes. Pour une liste complète des suppressions proposées, voir Suppressions pour PHP 7.3.

Alias de fonction mbstring non documentés : il y a un certain nombre d’alias de fonction mbstring non documentés qui sont des duplications de fonctions équivalentes utilisant le préfixe mb_. Par exemple, mbereg est un alias de mb_ereg.

Toutes ces fonctions seront marquées comme obsolètes et un avis d’obsolescence sera lancé lorsqu’elles sont rencontrées pendant la compilation.

Fonctions de recherche de chaîne avec un entier : ces fonctions fonctionnent généralement sur des aiguilles de chaînes. Si une aiguille sans chaîne est donnée, elle est convertie en entier et appliquée comme valeur ordinale d’un caractère (pour en savoir plus, consultez le manuel PHP). Voici un exemple tiré du RFC :

$str = "There are 10 apples";
var_dump(strpos($str, "10")); // int(10)
var_dump(strpos($str, 10));   // bool(false)

Ceci est considéré comme déroutant et cause des problèmes imprévisibles parce que le type peut changer avec la source de données de l’utilisateur. Pour cette raison, le RFC propose l’émission d’un avertissement de dépréciation si une aiguille sans chaîne est passée à l’une des fonctions suivantes :

  • strpos
  • strrpos
  • stripos
  • strripos
  • strstr
  • strchr
  • strrchr
  • stristr

Dans PHP 8.0, l’avertissement de dépréciation devrait être supprimé et les aiguilles devraient être automatiquement converties en chaînes.

La fonction fgetss() et le filtre de flux string.strip_tags : fgetss() et string.strip_tags suppriment les tags d’un flux lorsqu’ils les lisent. La fonction et le filtre exposent la fonctionnalité strip_tags(), rendant l’implémentation de strip_tags() plus complexe, car une machine d’état de stream est nécessaire. En outre, le RFC souligne un autre inconvénient de ces fonctions :

D’autre part, ces fonctions semblent être très peu utiles. strip_tags() lui-même, en raison de ses limitations et des bugs connus, a déjà très peu d’applications légitimes. Il n’est pas nécessaire de fournir un support natif pour les applications de stream en plus de cela.

Le RFC propose donc de marquer fgetss(), gzgetss() et SplFileObject::fgetss() comme obsolètes.

Que signifie PHP 7.3 pour les utilisateurs de WordPress ?

Selon la page officielle de WordPress Stats, au moment d’écrire ces lignes, seulement 32,9% des utilisateurs de WordPress ont migré vers PHP 7 ou plus. Seulement 4% utilisent PHP 7.2. Vous pouvez voir qu’une grande majorité d’utilisateurs, plus de 38%, fonctionnent toujours en PHP 5.6. Ce qui est encore plus effrayant, c’est que plus de 28,5% 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.

Version de PHP WordPress
Version de PHP WordPress

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

  • Les benchmarks officiels de PHP montrent que PHP 7 permet au système d’exécuter deux fois plus de requêtes par seconde que PHP 5.6, avec presque la moitié de la 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 réalisé nos propres benchmarks de performances. Et comme pour les benchmarks ci-dessus, nous avons vu que WordPress 5.0 avec PHP 7.3 pouvait exécuter presque trois fois plus de transactions (requêtes) par seconde que PHP 5.6.

Tests PHP WordPress 5.0
Tests PHP WordPress 5.0
  • Test WordPress 5.0 + PHP 5.6 : 91.64 req/sec
  • Test WordPress 5.0 + PHP 7.0 : 206.71 req/sec
  • Test WordPress 5.0 + PHP 7.1 : 210.98 req/sec
  • Test WordPress 5.0 + PHP 7.2 : 229.18 req/sec
  • Test WordPress 5.0 + PHP 7.3 : 253.20 req/sec 🏆

Il est également intéressant de noter que WordPress 4.9.8 sur PHP 7.3 était légèrement plus rapide que WordPress 5.0.

Tests PHP WordPress 4.9.8 PHP
Tests PHP WordPress 4.9.8 PHP
  • Test WordPress 4.9.8 + PHP 5.6 : 97.59 req/sec
  • Test WordPress 4.9.8 + PHP 7.0 : 221.42 req/sec
  • Test WordPress 4.9.8 + PHP 7.1 : 233.78 req/sec
  • Test WordPress 4.9.8 + PHP 7.2 : 250.36 req/sec
  • Test WordPress 4.9.8 PHP 7.3 : 276.31 req/sec 🏆

Beaucoup sont lents à mettre à jour simplement à cause du temps nécessaire pour tester tous leurs plugins et thèmes tiers afin de s’assurer qu’ils fonctionnent correctement. Mais il arrive souvent qu’ils ne l’aient tout simplement pas encore fait.

Vérifier votre version de PHP

Vous n’êtes pas sûr de la version de PHP que vous utilisez ? Une des façons les plus simples de vérifier est d’utiliser un outil comme Pingdom ou Google Chrome Devtools. Le premier en-tête de requête HTTP vous montrera généralement la version.

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

Ceci dépend du 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. Dans ce cas vous pourrez installer le plugin gratuit Version Info qui vous montrera quelques informations de base sur le serveur dans le pied de page de votre tableau de bord d’administration WordPress.

Vérifier la version de PHP dans WordPress
Vérifier la version de PHP dans WordPress

Alternativement, vous pouvez télécharger un fichier par FTP pour voir votre version de PHP. Ou vous pouvez toujours vous adresser à votre hébergeur et lui demander.

Mise à jour vers PHP 7.3

La version finale de PHP 7.3 est là et vous pouvez commencer à la tester immédiatement. Vous pouvez tester votre site WordPress localement ou vérifier vos scripts dans un environnement comme Docker, qui vous permet de tester différentes versions de PHP depuis la ligne de commande.

Vous pouvez également utiliser un environnement de développement, car il ressemblera davantage à un site de production en direct. Kinsta publiera PHP 7.3 dès qu’il sera disponible et aura été entièrement testé par notre équipe d’administrateurs système. Vous pouvez ensuite facilement créer un environnement de développement en un seul clic

Environnement de staging WordPress
Environnement de staging WordPress

Nous vous recommandons toujours de procéder à des tests approfondis avant de l’utiliser sur un site de production. Pour ce faire, il vous suffit de changer le moteur PHP du site de développement sous « Outils » et vous pouvez commencer à tester pour vous assurer de la compatibilité de vos plugins et thèmes tiers.

Changer pour PHP 7.3
Changer pour PHP 7.3

Une fois que vous avez confirmé que tout fonctionne, vous pouvez changer votre site de production en PHP 7.3 ou si vous avez effectué des changements, faites passer votre site de développement en production.

Résumé

La dernière et meilleure version de PHP est ici. Elle nous apportera des cadeaux comme des heredocs et des nowdocs flexibles, des virgules dans les appels de fonctions, des affectations de référence de list() et plus encore. Dans cet article, nous avons donné un aperçu de nos améliorations et modifications préférées, mais nous aimerions aussi savoir quelles sont vos améliorations et comment vous en profiterez. Faites-le nous savoir dans les commentaires ci-dessous.

Vous pouvez trouver la liste complète des propositions de PHP 7.3 sur la page Demandes de commentaires et les notes de mise à jour PHP 7.3 sur GitHub.

Carlo Daniele Kinsta

Carlo est un passionné de webdesign et de développement frontend. Il joue avec WordPress depuis plus de 10 ans, notamment en collaboration avec des universités et des établissements d'enseignement italiens et européens. Il a écrit des dizaines d'articles et de guides sur WordPress, publiés à la fois sur des sites web italiens et internationaux, ainsi que dans des magazines imprimés. Vous pouvez trouver Carlo sur X et LinkedIn.