PHP 8.4 : Dépréciations et suppressions

✒ La sortie de PHP 8.4 marque une nouvelle étape dans l’évolution du langage. Un grand nombre de modifications qui visent à rendre le langage plus stable, performant et maintenable peuvent impacter la compatibilité de certaines applications; entre les dépréciations de certaines syntaxes, la suppression de constantes obsolètes et la migration de fonctionnalités vers des extensions tierces, il est crucial de comprendre ces changements pour anticiper les ajustements nécessaires et garantir la stabilité de vos projets lorsque vous déciderez de mettre votre architecture à jour. Dans cet article, nous explorons les principales modifications à connaître pour naviguer sereinement vers PHP 8.4.

🔹 Déclaration implicite d’un argument nullable 

Il était possible de déclarer implicitement un argument nullable de la manière suivante : 

function exemple(array $value =null) {}

Cette syntaxe déclenche désormais une notice de dépréciation : 

Implicitly marking parameter $value as nullable is deprecated, the explicit nullable type must be used instead 

Pour y remédier, il faut donc s’assurer que toutes les variables nullables soient déclarées explicitement avec un point d’interrogation ou un type union : 

function exemple1(?array $value = null) {}
function exemple2(array|null $value = null) {}

🔹 Suppression de la constante E_STRICT 

La constante E_STRICT était utilisée par les fonctions error_reporting() et set_error_handler() pour les versions strictement inférieures à PHP7.4. Il déclenche maintenant une notice de dépréciation, il suffit donc de le supprimer. 

Dans le cas des applications qui doivent maintenir une compatibilité avec la version PHP7.3 ou antérieure, voici un exemple de condition à envisager : 

if (PHP_VERSION_ID >= 70400) {
    error_reporting(E_ALL & ~E_DEPRECATED); 
} else {
    error_reporting(E_ALL & ~E_DEPRECATED & ~E_STRICT); 
}

🔹 Appeler la fonction session_set_save_handler() avec plus de deux arguments 

La fonction session_set_save_handler() accepte actuellement deux définitions. La première qui pouvait accepter jusqu’à 9 arguments est dépréciée en faveur de la seconde qui n’accepte que deux arguments :

• une instance de classe qui implémente SessionHandlerInterface
• un booléen $register_shutdown (true par défaut) qui utilisera la fonction session_write_close() comme callback de la fonction register_shutdown_function() s’il n’est pas false. 

Cette dépréciation de la définition deviendra une suppression définitive à partir de PHP 9.0. 

🔹 Constante CURLOPT_BINARYTRANSFER dépréciée 

Cette constante n’avait plus d’effet depuis PHP 5.1.2 et peut donc être supprimée sans risque de vos appels cURL. 

🔹 Migration de plusieurs extensions vers PECL : oci8, pdo_oci8, imap, pspell 

Les extensions oci8 et pdo_oci8 permettent d’utiliser les bases de données Oracle sur PHP. En raison de leur dépendance à des librairies propriétaires Oracle et au travail de maintenance requis pour corriger tous les bugs qui se sont accumulés, ces extensions sont retirées du core PHP pour être migrées vers PECL. 

L’extension IMAP permet d’opérer sur les boîtes mails avec le protocole du même nom mais la librairie en C  sur laquelle elle repose n’a pas reçu de mise à jour depuis 2018. Il est recommandé d’utiliser une solution plus robuste, comme imap-bundle pour Symfony par exemple. 

L’extension Pspell permet de vérifier l’orthographe d’un mot et de suggérer des corrections. Comme pour IMAP, cette migration vers PECL s’explique par le fait que les dépendances de cette extension n’ont pas reçu de mise à jour depuis plusieurs années. Il est possible de migrer vers la librairie Enchant qui fait partie du core PHP et supporte davantage de backends. 

En PHP 8.4, utiliser les flags associés dans le script ./configure lancera un warning : 

configure: WARNING: unrecognized options: --with-pdo-oci

configure: WARNING: unrecognized options: --with-oci8 

configure: WARNING: unrecognized options: --with-imap 

configure: WARNING: unrecognized options: --with-imap-ssl 

configure: WARNING: unrecognized options: --with-pspell 

Toutes ces extensions doivent donc être installées depuis PECL ou remplacées par une meilleure alternative. 

✒ PHP 8.4 s’inscrit dans une dynamique de modernisation en éliminant des éléments obsolètes et en favorisant des pratiques de développement plus explicites et sécurisées. Ces changements peuvent sembler contraignants pour les projets plus anciens, mais ils permettent aussi de renforcer la robustesse des applications. En anticipant les ajustements nécessaires et en adoptant des alternatives pérennes, les développeurs pourront tirer pleinement parti de cette nouvelle version. J’espère que cet aperçu vous aidera à aborder cette transition avec plus de sérénité et de clarté.