WordPress 7.1 Beta 3 : testez vos blocs métier Checklist avant migration
WordPress 7.1 Beta 3, publiée le 22 juillet 2026, est une version de test. Pour les équipes qui maintiennent des blocs métier, le sujet prioritaire est déjà la compatibilité avec l’éditeur de publication rendu dans une iframe.
WordPress 7.1 Beta 3 est destinée aux tests et ne doit pas être installée sur un site de production. Son intérêt, pour un projet métier, est de fournir une fenêtre de vérification avant la release candidate prévue le 5 août 2026 et la version finale annoncée pour le 19 août 2026.
Le point le plus structurant concerne l’éditeur de publication dans une iframe. Un bloc ancien ou conçu en supposant que le document de l’administration est directement accessible peut donc afficher un rendu différent, perdre des styles ou ne plus déclencher certaines actions.
Commencer par les blocs réellement utilisés
Ne testez pas seulement le bloc le plus simple. Sélectionnez les blocs métier qui utilisent des champs ACF, des données REST, des contrôles personnalisés, des blocs imbriqués, des variations, des styles propres au thème ou des actions asynchrones.
Constituez une copie de préproduction avec le même thème, les mêmes extensions et un jeu de contenus représentatif. Un test réalisé avec un thème vierge ou une base vide peut masquer une incompatibilité liée au contexte réel du site.
Vérifier la migration vers Block API version 3
La documentation WordPress recommande de faire fonctionner les blocs avec Block API version 3 dans l’éditeur en iframe. Vérifiez le fichier block.json, l’usage de useBlockProps() dans l’éditeur et de useBlockProps.save() pour les blocs statiques.
Le passage à l’API version 3 ne consiste pas à modifier un nombre dans block.json. Il faut vérifier le comportement du bloc dans son nouvel environnement d’exécution, puis corriger les dépendances implicites au document parent, aux styles de l’admin ou à des sélecteurs trop généraux.
Tester les styles, scripts et interactions
Pour chaque bloc, testez l’insertion, la sélection, la modification des attributs, l’aperçu, la sauvegarde, la réouverture du contenu et l’affichage côté visiteur. Reproduisez aussi les cas où le bloc est placé dans une colonne, un groupe, une boucle de requête ou une structure issue d’un template FSE.
Contrôler les données et les actions
Un bloc métier peut sembler compatible tout en échouant sur son parcours principal. Vérifiez les formulaires, les sauvegardes automatiques, les permissions, les appels vers une API interne, les listes filtrées, les médias et les valeurs issues d’ACF ou d’un autre système de champs.
La compatibilité ne se limite pas à l’affichage initial. Un bloc doit conserver ses données après sauvegarde, rester éditable après réouverture et produire un rendu cohérent côté visiteur. Documentez chaque écart avec la version de WordPress, le thème, les extensions actives et une procédure de reproduction.
Décider avec des preuves, pas avec une impression
Avant de planifier la mise à jour, classez les résultats en trois catégories : compatible, compatible sous réserve et bloquant. Un avertissement de console isolé ne produit pas nécessairement une panne, mais une perte de données, un formulaire inutilisable ou un rendu cassé dans l’éditeur doit empêcher la mise en production.
WordPress 7.1 Beta 3 est un jalon de test, pas une garantie de compatibilité finale. Les fonctionnalités peuvent encore évoluer avant la release candidate. En revanche, attendre la version définitive pour découvrir qu’un bloc dépend de l’ancien éditeur réduit fortement le temps disponible pour corriger proprement.
Poursuivez votre lecture
Trois articles pour aller plus loin.
Besoin d’un avis clair sur votre site ?
Premier échange clair · Priorités concrètes
Je peux vous aider à comprendre la situation, identifier les points importants et définir une intervention adaptée.
Premier échange gratuit · Sans engagement · Réponse rapide