Un site en production accumule des extensions, un thème, parfois du code sur mesure, écrits à des dates différentes par des personnes différentes. Chaque mise à jour de WordPress ou de PHP fait courir le même risque : qu’une fonction utilisée hier ait changé de comportement, voire disparu.
Comment WordPress gère la sienne
Le cœur de WordPress est réputé pour sa politique stricte de compatibilité ascendante : les fonctions publiques restent disponibles très longtemps, quitte à être marquées « dépréciées » via _deprecated_function() plutôt que supprimées brutalement. Une extension bien écrite suit le même principe envers ses propres utilisateurs.
function ancienne_fonction_util( $valeur ) {
_deprecated_function( __FUNCTION__, '2.0.0', 'nouvelle_fonction_util' );
return nouvelle_fonction_util( $valeur );
}Dans la pratique d’une extension
Avant de publier une nouvelle version majeure, il est courant de vérifier le comportement du code sur l’ancienne et la nouvelle version cible de PHP, et de consulter le journal des changements (« changelog ») de WordPress pour repérer les fonctions dépréciées. L’en-tête d’extension déclare d’ailleurs une version minimale et une version testée jusqu’à, ce qui aide l’utilisateur à anticiper les risques.
Bon à savoir
- Activer
WP_DEBUGen environnement de test fait remonter les avertissements de dépréciation dans les journaux, avant qu’ils ne deviennent des erreurs fatales en production. - Une rupture de compatibilité ascendante mal anticipée est une cause fréquente d’écrans blancs après une mise à jour automatique.