Préparer la migration depuis PHP 7.4

Pourquoi migrer

Chaque version de PHP ne reçoit des correctifs que pendant une durée limitée. Ensuite, elle continue de fonctionner, mais plus personne ne corrige les failles de sécurité qu’on y trouve, et les nouvelles versions des bibliothèques cessent de la prendre en charge. Fin de prise en charge des différentes versions (état en octobre 2026, la vue d’ensemble à jour est sur php.net) :

• PHP 7.4 – 28 novembre 2022,
• PHP 8.0 – 26 novembre 2023,
• PHP 8.1 – 31 décembre 2025,
• PHP 8.2 – 31 décembre 2026,
• PHP 8.3 – 31 décembre 2027,
• PHP 8.4 – 31 décembre 2028,
• PHP 8.5 – 31 décembre 2029.

Vers quelle version migrer

Passez directement à la version la plus récente que propose votre hébergement et que prennent en charge les bibliothèques du site. Vous n’êtes pas obligé de passer étape par étape par 8.0, 8.1 et les versions suivantes, mais les changements de toutes les versions intermédiaires vous concernent aussi. Le manuel PHP les décrit dans le chapitre « Migration de PHP 7.4.x à PHP 8.0.x » (php.net) et dans les chapitres suivants pour chaque version. L’article Changements de PHP 8 qui cassent l’ancien code résume les changements les plus importants.

Les constantes de PHP indiquent sous quelle version le script s’exécute :

echo PHP_MAJOR_VERSION.".".PHP_MINOR_VERSION;

En PHP 8.4, cela affiche :

8.4

Pour les comparaisons dans les conditions, utilisez le nombre PHP_VERSION_ID (PHP 8.1.0 a 80100, PHP 8.4.0 a 80400), par exemple if(PHP_VERSION_ID >= 80100).

Ordre des étapes

1. Copie du site. Faites vos essais sur une copie (sur votre ordinateur ou sur un domaine de test), pas sur le site en production. Sauvegardez les fichiers et la base de données.
2. Tous les messages dans l’ancienne version. PHP 7.4 signale comme Deprecated la plupart des choses que PHP 8.0 a supprimées. Parcourez le site avec les messages activés et corrigez-les.
3. Contrôle de la syntaxe dans la nouvelle version par php -l et éventuellement par des outils qui vérifient le code sans l’exécuter.
4. Bibliothèques. Mettez-les à jour vers des versions qui prennent en charge la nouvelle version de PHP.
5. Test de tout le site dans la nouvelle version – pages, formulaires, administration, envoi d’e-mails, tâches cron. Surveillez le journal des erreurs.
6. Bascule sur l’hébergement. La version se change généralement dans l’administration de l’hébergement pour le domaine concerné. Après la bascule, parcourez le journal des erreurs et gardez la possibilité de revenir en arrière.

Messages Deprecated en PHP 7.4

Sur l’ordinateur de développement, activez tous les messages (sur le site en production, enregistrez-les seulement dans un journal, voir Messages d’erreur en production) :

error_reporting(E_ALL);
ini_set("display_errors", "1");

Exemple : accès à un caractère d’une chaîne par des accolades.

$word = "PHP";
echo $word{0};

PHP 7.4 affiche P et le message Deprecated: Array and string offset access syntax with curly braces is deprecated. PHP 8 n’exécute pas du tout le fichier. Les versions 8.0 à 8.3 signalent Fatal error: Array and string offset access syntax with curly braces is no longer supported, depuis PHP 8.4 c’est une erreur de syntaxe générale (Parse error). La correction est simple : $word[0].

Plus sournois est l’opérateur conditionnel imbriqué sans parenthèses. PHP l’évalue à partir de la gauche, si bien que le résultat est parfois différent de ce que voulait l’auteur :

$points = 95;
echo $points > 90 ? "excellent" : $points > 50 ? "bien" : "faible";

Avec 95 points, PHP 7.4 affiche « bien » et un message Deprecated, PHP 8 se termine par l’erreur Unparenthesized `a ? b : c ? d : e` is not supported. Ce sont les parenthèses qui décident de ce qui est voulu :

$points = 95;
echo $points > 90 ? "excellent" : ($points > 50 ? "bien" : "faible");

excellent

Reçoivent aussi un message Deprecated en PHP 7.4, entre autres, les fonctions money_format(), get_magic_quotes_gpc(), is_real(), array_key_exists() utilisée sur un objet et implode() avec les paramètres inversés (le tableau, puis le séparateur). En PHP 8.0, elles ne fonctionnent plus. Les fonctions each() et create_function() sont signalées comme obsolètes depuis la version 7.2.

Les messages n’apparaissent que pour le code qui s’exécute réellement. Il faut donc parcourir tout le site, y compris l’administration et les actions plus rares. Il est pratique d’enregistrer les messages dans un fichier : ini_set("log_errors", "1") et ini_set("error_log", "…/php-errors.log").

Contrôle de la syntaxe

La commande php -l n’exécute pas le fichier, elle vérifie seulement sa syntaxe :

php -l index.php

Pour un fichier sans erreur, elle affiche No syntax errors detected in index.php. Sous Linux, vous pouvez vérifier tout un dossier et n’afficher que les fichiers avec des erreurs :

find . -name "*.php" -exec php -l {} \; | grep -v "No syntax errors"

Lancez-le dans la nouvelle version de PHP. Il détecte les erreurs de syntaxe (par exemple l’opérateur conditionnel imbriqué ci-dessus), mais pas les fonctions supprimées ni le comportement modifié – cela n’apparaît qu’à l’exécution.

Les outils PHPStan (trouve les appels de fonctions inexistantes et les mauvais types) et Rector (sait apporter lui-même une partie des changements pour la nouvelle version) examinent aussi le code sans l’exécuter. On les installe avec Composer comme dépendances de développement, par exemple composer require --dev phpstan/phpstan rector/rector. Vérifiez toujours les changements de Rector avant de les accepter.

Bibliothèques

Les bibliothèques sont souvent le plus grand obstacle lors de la migration : l’ancienne version d’une bibliothèque ne fonctionne pas en PHP 8 et la nouvelle ne prend plus en charge PHP 7.4. Si le site utilise Composer, la commande composer why-not php 8.4 affiche les paquets qui n’admettent pas la version de PHP indiquée. Les bibliothèques copiées à la main dans le site (par exemple un ancien PHPMailer) se mettent à jour de la même façon – téléchargez la nouvelle version et vérifiez si sa façon de l’utiliser n’a pas changé.

Du code pour les deux versions

Avant la bascule du site, le code doit fonctionner aussi bien dans l’ancienne version que dans la nouvelle. Les nouvelles fonctions peuvent être ajoutées à l’ancienne version par un remplacement à vous (polyfill) :

if(!function_exists("str_contains"))
  {
    function str_contains(string $haystack, string $needle): bool
      {
        return $needle === "" || strpos($haystack, $needle) !== false;
      }
  }
var_dump(str_contains("Migrer vers PHP 8", "PHP"));

bool(true)

Le paquet symfony/polyfill-php80 et les suivants pour les versions plus récentes proposent des remplacements tout prêts.

La nouvelle syntaxe (match, opérateur ?->, arguments nommés…) ne peut pas être remplacée ainsi. PHP 7.4 n’exécute pas du tout un fichier qui la contient, même si la ligne en question ne s’exécute jamais :

if(PHP_VERSION_ID >= 80000)
  {
    echo match(1) { 1 => "PHP 8" };
  }

PHP 8

PHP 7.4 se termine par l’erreur Parse error. Tant que le site fonctionne aussi sous PHP 7.4, n’utilisez pas la nouvelle syntaxe ou placez-la dans un fichier à part, qui n’est chargé que dans une version plus récente.

Vérifiez aussi sur l’hébergement la version de PHP de la ligne de commande : les tâches cron peuvent fonctionner sous une autre version que le site.

Articles connexes :
Changements de PHP 8 qui cassent l’ancien code
Messages d’erreur en production
Attributs et autres nouveautés de PHP 8.1 à 8.5