PHP 8.3 est sorti le 23 novembre 2023, et comme à chaque montée de version majeure, la question qui remonte du support technique est toujours la même : « est-ce que mon extension va continuer à fonctionner ? » La bonne nouvelle, c’est que PHP 8.3 casse beaucoup moins de choses que la transition 7 vers 8. La mauvaise, c’est que les quelques points de friction touchent justement les habitudes de code qu’on retrouve dans une bonne partie du parc d’extensions maison.
Cet article passe en revue les changements de PHP 8.3 qui ont un impact concret sur du code d’extension existant, sans revenir sur les dépréciations déjà traitées à l’occasion de PHP 8.2 (propriétés dynamiques notamment) ni anticiper PHP 8.4, qui suivra son propre calendrier.
Les constantes de classe typées
Nouveauté la plus visible : une constante de classe peut désormais porter un type déclaré, exactement comme une propriété.
class WPM_Statuts {
public const string BROUILLON = 'brouillon';
public const string PUBLIE = 'publie';
public const string ARCHIVE = 'archive';
}Ce n’est pas une obligation : le code existant sans typage continue de fonctionner à l’identique. Le risque apparaît si une extension redéfinit une constante dans une classe fille avec un type incompatible — PHP 8.3 lève alors une erreur fatale de covariance, là où l’ancien code se contentait d’écraser silencieusement la valeur. Sur un parc d’extensions qui utilisent l’héritage de constantes pour des systèmes de statuts ou de rôles personnalisés, ce point mérite un audit ciblé avant la mise à niveau.
readonly appliqué à toute une classe
Jusqu’à PHP 8.2, il fallait marquer chaque propriété readonly individuellement. PHP 8.3 permet de le faire au niveau de la classe entière :
readonly class WPM_Commande {
public function __construct(
public int $id,
public string $statut,
public float $montant,
) {}
}
L’effet de bord à connaître : une classe readonly ne peut plus être étendue par une classe qui ne l’est pas elle-même. Sur des extensions qui exposent des value objects destinés à être surchargés par des extensions tierces ou par un thème, ce choix architectural doit être pris consciemment — il ferme la porte à l’extensibilité par héritage, au profit de la composition.
json_validate() et la fin du décodage inutile
Combien d’extensions valident une charge utile JSON reçue via wp_remote_post en appelant json_decode() puis en vérifiant json_last_error(), sans jamais utiliser le résultat décodé ? PHP 8.3 introduit json_validate(), qui retourne un simple booléen sans construire la structure de données en mémoire :
if ( ! json_validate( $payload_brute ) ) {
return new WP_Error( 'wpm_json_invalide', __( 'Charge JSON invalide.', 'wpm' ) );
}
$donnees = json_decode( $payload_brute, true );Le gain n’est pas seulement de lisibilité : sur un webhook qui reçoit des payloads volumineux, éviter un décodage complet juste pour une vérification de forme réduit la pression mémoire, en particulier sur un hébergement mutualisé où la limite est basse.
Ce qui ne casse rien, contrairement aux rumeurs
- Les fonctions dépréciées de PHP 8.1/8.2 (propriétés dynamiques,
utf8_encode) restent au même statut : dépréciées, pas supprimées. - Les hooks WordPress (
add_action,add_filter) ne sont pas affectés : leur signature n’a jamais dépendu de fonctionnalités récentes du langage. - Le typage strict (
declare(strict_types=1)) reste optionnel et se comporte comme avant.
Avant toute montée de version PHP en production, la vérification qui coûte le moins cher reste d’activer
WP_DEBUGsur une copie de staging et de parcourir les logs pendant une navigation complète du site, admin compris.
Notre verdict
PHP 8.3 est une version raisonnable à cibler pour toute nouvelle extension livrée fin 2023 ou en 2024 : les gains de performance du JIT et les nouvelles capacités de typage valent la peine, et la compatibilité ascendante reste globalement bonne. Le point de vigilance réel se limite à deux zones précises — l’héritage de constantes typées et les classes readonly — qui concernent surtout les extensions bâties sur une architecture orientée objet un peu ambitieuse. Pour le reste du code procédural classique, la migration devrait se passer sans accroc majeur.
