Chaque montée de version majeure de WordPress mérite le même traitement méthodique de la part d’un auteur d’extension : lire le journal des modifications techniques, pas seulement l’article de présentation grand public, et vérifier point par point ce qui touche réellement son propre code. Pour WordPress 6.8, l’attention médiatique s’est largement concentrée sur le Speculative Loading (préchargement anticipé des pages) qui ne fait pas l’objet de cet article — il concerne d’abord le rendu front générique, pas l’API que manipule directement la plupart des extensions.
Ce qui mérite une vérification active côté extension, en revanche, touche au hachage des mots de passe, à plusieurs évolutions de l’API des templates, et à des ajustements de compatibilité PHP qu’il vaut mieux anticiper avant qu’un utilisateur ne remonte un problème en production.
Le changement de hachage des mots de passe vers bcrypt
WordPress 6.8 fait évoluer l’algorithme de hachage des mots de passe utilisateur vers bcrypt, un algorithme plus robuste que celui utilisé historiquement par le cœur. Pour la grande majorité des extensions, ce changement est totalement transparent : les fonctions officielles wp_hash_password() et wp_check_password() gèrent la transition en interne, y compris la compatibilité avec les anciens hachages déjà stockés en base.
La vérification à faire concerne uniquement les extensions qui, pour une raison ou une autre, réimplémentent leur propre logique de vérification de mot de passe plutôt que de passer par ces fonctions officielles — un cas rare mais qui existe, notamment sur des extensions d’authentification tierce ou de connexion unique développées avant l’existence de ces API. Tout code qui compare directement une chaîne de mot de passe à une valeur stockée sans passer par wp_check_password() doit être audité et corrigé sans délai.
// À proscrire : vérification maison qui ignore la logique officielle
if ( md5( $mot_de_passe_saisi ) === $hash_stocke ) { ... }
// À utiliser systématiquement
if ( wp_check_password( $mot_de_passe_saisi, $hash_stocke, $user_id ) ) { ... }
Évolutions de l’API des templates et des styles
Plusieurs fonctions liées à la résolution des templates blocs et à la génération des styles globaux ont été affinées dans cette version, avec des ajustements sur la façon dont les variations de style sont fusionnées entre thème parent et thème enfant. Une extension qui enregistre ses propres variations de style via theme.json partiel, ou qui filtre le tableau de styles globaux via des hooks comme wp_theme_json_data_theme, doit revérifier que la fusion se comporte toujours comme attendu, en particulier si elle cible des chemins profonds dans la structure de styles.
Liste de vérification pour une mise à jour de compatibilité
- Auditer tout code qui manipule des mots de passe ou des hachages en dehors des fonctions officielles
wp_hash_password()/wp_check_password(), et corriger sans délai le cas échéant. - Rejouer les scénarios de test sur les écrans utilisant des templates blocs personnalisés, en particulier si l’extension enregistre des styles ou des variations via
theme.json. - Vérifier la compatibilité avec les versions de PHP officiellement prises en charge par cette version du cœur, en particulier sur les fonctionnalités de typage strict si l’extension a été mise à jour récemment.
- Passer en revue le journal des dépréciations affichées en environnement de débogage (
WP_DEBUG_LOGactif) sur un site de test représentatif, avec un scénario d’usage complet de l’extension. - Mettre à jour la balise
Tested up todu fichier d’en-tête de l’extension uniquement après une vraie campagne de test, pas par automatisme.
Ce qui ne change pas et ne mérite pas d’inquiétude
- Les hooks classiques (actions et filtres) du cœur restent stables ; aucune suppression majeure de hook couramment utilisé n’accompagne cette version.
- L’API REST ne change pas de structure d’authentification ; les nonces et l’authentification par application passwords continuent de fonctionner à l’identique.
- Les fonctions de gestion des options, des metadonnées et des taxonomies restent inchangées dans leur signature.
Notre méthode pour chaque version majeure reste la même depuis des années : on lit d’abord le « Field Guide » technique publié sur le site des développeurs WordPress avant même l’article de présentation grand public, parce que c’est cette source qui liste précisément les changements d’API, pas les nouveautés visibles pour l’utilisateur final.
Ce que le Speculative Loading implique malgré tout
Même si cet article ne détaille pas cette fonctionnalité, un point mérite d’être signalé pour les extensions qui déclenchent des actions effectives via un simple survol ou un clic de lien (suivi analytique personnalisé, actions AJAX déclenchées côté client) : le préchargement anticipé de pages peut, dans certaines configurations, déclencher un chargement de page avant même un clic explicite de l’utilisateur. Toute extension qui suppose qu’une requête de page correspond nécessairement à une intention affirmée de navigation devrait revoir cette hypothèse, sans que cela remette en cause son fonctionnement général.
En résumé
WordPress 6.8 n’introduit pas de rupture majeure pour la plupart des extensions, mais deux points méritent une vérification active : tout code qui gère des mots de passe en dehors des fonctions officielles, à corriger sans attendre compte tenu du passage à bcrypt, et les extensions qui interagissent finement avec les styles globaux et les templates blocs. Une campagne de test méthodique, plutôt qu’une simple lecture de la liste des nouveautés, reste la seule façon fiable de garantir la compatibilité avant de mettre à jour la balise Tested up to.
