WordPress 6.8 est sortie le 15 avril 2025. Contrairement aux annonces marketing centrées sur le Speculative Loading et le passage de bcrypt pour le hachage des mots de passe — deux sujets qui ne concernent pas directement l’écriture de blocs personnalisés — cette version apporte une série d’ajustements plus discrets côté APIs d’éditeur, qui méritent leur propre inventaire pour qui maintient des blocs en production.
Rien qui casse la compatibilité de façon brutale, mais plusieurs points à vérifier avant de considérer une extension de blocs comme testée sur cette version.
Stabilisation de composants internes
Plusieurs composants de @wordpress/components auparavant marqués expérimentaux (préfixés __experimental dans leur export) passent à un statut stable dans cette version, ce qui change leur nom d’export officiel. Les blocs qui importaient ces composants sous leur ancien nom expérimental continuent généralement de fonctionner grâce à des alias de rétrocompatibilité, mais un avertissement de dépréciation apparaît désormais en console de développement.
// Ancien import, toujours fonctionnel mais déprécié
import { __experimentalToolsPanel as ToolsPanel } from '@wordpress/components';
// Import recommandé après stabilisation
import { ToolsPanel } from '@wordpress/components';
Sur nos projets, un simple passage en revue des imports préfixés __experimental dans le code des blocs personnalisés a suffi à nettoyer ces avertissements, sans changement de comportement visible pour l’utilisateur final.
Ajustements sur les blocs de grille et de groupe
Le bloc Grille (core/group avec la variation de disposition grille) reçoit des ajustements sur la gestion des unités de dimensionnement de ses colonnes, avec une meilleure cohérence entre l’aperçu de l’éditeur et le rendu front pour les valeurs exprimées en unités relatives. Les blocs personnalisés qui héritent du support layout pour proposer leurs propres options de disposition doivent vérifier que leurs styles générés restent corrects avec ces ajustements, en particulier si le bloc surcharge manuellement le CSS de disposition plutôt que de s’appuyer entièrement sur le support natif.
Une dépréciation à anticiper
La signature de certains filtres de rendu de bloc côté serveur poursuit sa clarification amorcée dans les versions précédentes, avec un avertissement de dépréciation renforcé sur l’usage direct de la variable superglobale $block non typée dans certains contextes de filtre historiques, au profit de l’objet WP_Block désormais systématiquement transmis. Les blocs qui manipulaient encore ces filtres à l’ancienne (hérités d’une syntaxe antérieure à l’introduction de WP_Block) affichent un avertissement PHP en mode débogage, sans casser le rendu pour l’instant.
// Ancienne pratique, dépréciée mais encore tolérée
add_filter( 'render_block', function ( $contenu, $bloc_array ) {
return $contenu;
}, 10, 2 );
// Pratique recommandée, avec accès à l'instance WP_Block complète
add_filter( 'render_block', function ( $contenu, $bloc_array, $instance ) {
// $instance est un objet WP_Block, avec accès à ->context, ->parsed_block, etc.
return $contenu;
}, 10, 3 );
Autres points relevés
- Amélioration de la gestion des raccourcis clavier dans l’éditeur, avec une meilleure cohérence entre les blocs natifs et les blocs personnalisés qui exposent leurs propres raccourcis via
useShortcut. - Ajustements mineurs de l’API de
ServerSideRender, sans changement de signature, mais avec une meilleure gestion des erreurs réseau affichées dans l’éditeur en cas d’échec de la requête de prévisualisation. - Corrections de bugs sur le comportement de
useEntityProppour certains champs de métadonnées personnalisées enregistrés avecregister_post_meta()et un schéma de typeobject.
Ce qui n’a pas bougé
Contrairement à d’autres versions majeures marquées par un changement structurel visible (le zoom out en 6.7, les script modules en 6.5), la 6.8 ne modifie aucune API fondamentale de déclaration ou d’enregistrement de bloc. register_block_type(), block.json et le cycle edit()/save() restent identiques dans leur usage courant.
Sur ce projet de mise à jour, la seule action réellement nécessaire a été de traiter les avertissements de dépréciation des imports
__experimental— une demi-journée de travail pour une dizaine de blocs personnalisés, sans aucun changement de comportement visible côté utilisateur.
En résumé
WordPress 6.8 n’impose aucune migration urgente côté développement de blocs, mais mérite un passage en revue des imports de composants expérimentaux et des filtres de rendu à l’ancienne syntaxe, tous deux désormais signalés comme dépréciés en mode débogage. Une vérification rapide qui évite de futures mauvaises surprises quand ces alias de rétrocompatibilité finiront, un jour, par disparaître complètement.
