Chaque montée de version PHP apporte son lot d’opportunités d’écriture plus propre et son lot de vérifications à mener avant de pousser une mise à jour serveur en production. PHP 8.4 introduit deux nouveautés de langage particulièrement utiles pour qui écrit des classes de domaine dans une extension WordPress un peu structurée : les property hooks et la visibilité asymétrique. PHP 8.5 poursuit sur cette lancée avec quelques ajustements supplémentaires. Cet article ne revient pas sur les dépréciations déjà couvertes pour PHP 8.2 (propriétés dynamiques), mais se concentre sur ce qui change avec ces deux versions plus récentes.
Property hooks : la fin des getters et setters manuels
Avant PHP 8.4, encapsuler proprement une propriété — valider une valeur à l’écriture, calculer une valeur dérivée à la lecture — obligeait à écrire une propriété privée accompagnée de méthodes getXxx() et setXxx() dédiées, un schéma répétitif qui alourdit chaque classe de domaine. Les property hooks permettent d’attacher directement ce comportement à la déclaration de la propriété :
class Abonnement {
public string $email {
set {
if ( ! is_email( $value ) ) {
throw new InvalidArgumentException( 'Adresse e-mail invalide.' );
}
$this->email = strtolower( $value );
}
}
public int $joursRestants {
get => max( 0, $this->dateExpiration->diff( new DateTimeImmutable() )->days );
}
public function __construct(
string $email,
private readonly DateTimeImmutable $dateExpiration
) {
$this->email = $email;
}
}
La propriété email valide et normalise sa valeur directement à l’assignation, sans méthode setEmail() séparée à appeler explicitement — un code appelant qui écrit simplement $abonnement->email = 'Client@Exemple.fr' bénéficie automatiquement de la validation et de la normalisation. La propriété joursRestants, elle, n’a pas de valeur stockée propre : elle est entièrement calculée à la lecture, ce qui évite un champ redondant à synchroniser manuellement.
Visibilité asymétrique : lecture publique, écriture protégée
Un besoin très courant dans une classe de domaine : exposer une propriété en lecture à l’extérieur, mais n’autoriser sa modification que depuis l’intérieur de la classe ou d’une sous-classe. Avant PHP 8.4, cela nécessitait une propriété privée et une méthode d’accès en lecture. La visibilité asymétrique permet de l’exprimer directement dans la déclaration :
class Commande {
public private(set) string $statut = 'en_attente';
public function marquerPayee(): void {
$this->statut = 'payee'; // autorisé, on est à l'intérieur de la classe
}
}
$commande = new Commande();
echo $commande->statut; // lecture autorisée, affiche 'en_attente'
$commande->statut = 'payee'; // Erreur : écriture interdite depuis l'extérieur
Ce mécanisme réduit sensiblement le nombre de méthodes « getter-only » qu’une classe de domaine devait auparavant multiplier pour protéger son état interne, tout en gardant une API de lecture directe et lisible pour le code appelant.
Dépréciations à vérifier avant mise à jour serveur
Comme à chaque version, plusieurs fonctions et comportements historiques sont marqués comme dépréciés, sans être supprimés immédiatement. Pour une extension WordPress, les points qui méritent une vérification active concernent principalement les fonctions de manipulation de tableaux et de chaînes dont le comportement sur des valeurs implicitement converties (null, valeurs numériques mélangées à des chaînes) devient plus strict, générant des avis de dépréciation là où le code tolérait auparavant ce genre d’ambiguïté sans broncher.
Méthode de vérification recommandée
- Activer
WP_DEBUG_LOGsur un environnement de test sous PHP 8.4, avec un scénario d’usage complet de l’extension. - Passer en revue chaque ligne de dépréciation remontée, en priorisant celles qui touchent du code exécuté fréquemment (hooks appelés à chaque chargement de page).
- Corriger en amont plutôt que d’attendre la suppression effective de la fonctionnalité concernée dans une version ultérieure du langage.
Adopter les property hooks sans casser la compatibilité descendante
Un point de vigilance pour un auteur d’extension distribuée largement : les property hooks et la visibilité asymétrique nécessitent PHP 8.4 au minimum. Si l’extension doit rester compatible avec des versions de PHP antérieures pour des raisons de parc installé, ces fonctionnalités doivent être réservées à des classes internes non exposées publiquement, ou l’extension doit clairement relever sa version minimale de PHP requise dans son en-tête, avec une communication explicite aux utilisateurs concernés.
/**
* Requires PHP: 8.4
*/
Sur nos projets internes qui ne dépendent pas d’un large parc d’hébergement mutualisé ancien, on a commencé à adopter les property hooks progressivement, classe par classe, plutôt que de tout réécrire d’un coup. Le gain de lisibilité est réel, mais rien n’oblige à migrer une base de code entière du jour au lendemain.
Et PHP 8.5
PHP 8.5 poursuit dans la continuité de 8.4 sans rupture majeure pour les auteurs d’extensions WordPress, avec des ajustements de performance interne et des affinages mineurs des fonctionnalités introduites en 8.4. La vérification à mener reste la même méthode : environnement de test dédié, journalisation active des dépréciations, et correction avant bascule en production plutôt qu’après.
En résumé
Les property hooks et la visibilité asymétrique de PHP 8.4 apportent un vrai confort d’écriture pour les classes de domaine d’une extension bien structurée, en réduisant la verbosité des getters et setters manuels sans sacrifier l’encapsulation. Leur adoption doit néanmoins tenir compte de la version minimale de PHP exigée par l’extension, avec une communication claire si celle-ci doit évoluer. Les dépréciations qui accompagnent ces versions, moins spectaculaires, méritent tout autant une vérification méthodique avant toute mise à jour de serveur en production.
