Une version de test, pas une mise à jour de production
WordPress.org a publié Beta 4 le 3 novembre et précise que cette version sert uniquement au développement et aux tests. Elle ne doit pas être installée sur un site en production ou critique. La version finale de WordPress 7.2 est planifiée pour le 8 décembre 2026, mais une date de calendrier reste un objectif. Le projet explique qu’il n’y a pas eu d’annonce séparée pour Beta 3, car WordPress 7.1.4 comprenait déjà cette build de développement.
Cet article complète le guide CherTra News déjà consacré à la préparation de WordPress 7.2. Celui-ci présente le cycle général et la planification ; cette mise à jour décrit les changements signalés pour Beta 4 et leur test prudent. Les vérifications de compatibilité de l’article précédent restent nécessaires.
Ajustements d’accessibilité, d’éditeur et d’API
La note Beta 4 décrit des progrès sur l’accessibilité, la fiabilité de l’éditeur et les API, ainsi que des corrections de bugs et de compatibilité. Elle cite notamment une meilleure visibilité du focus clavier sous le mode Windows High Contrast, des retouches de l’administration et des corrections pour l’alignement des blocs de droite à gauche et l’espacement personnalisé. Le travail développeur concerne Abilities API, l’extensibilité DataViews et le comportement de la REST API.
La gestion des traductions évolue également : les administrateurs peuvent examiner individuellement les mises à jour disponibles dans l’écran Updates et les installer sélectivement, selon un parcours comparable à celui des extensions et thèmes. Une note beta ne garantit ni que chaque modification est définitive ni que chaque extension est compatible. Consulter les tickets Trac et commits Gutenberg associés, puis les notes ultérieures.
Tester un site représentatif sans risquer la production
Utiliser une copie de préproduction ou un environnement local isolé avec une sauvegarde récente et une restauration vérifiée. Noter les versions de WordPress, PHP, base de données, thème et extensions ; tester les flux réels : édition et publication, modèles, formulaires, contenu RTL si nécessaire, traductions, tâches planifiées et intégrations. Tester une installation neuve et une mise à niveau si ces scénarios concernent le projet.
Ne pas connecter la beta à des données client réelles ni à un site critique. Éviter de l’installer sur une copie de production uniquement pour voir l’administration. Signaler les défauts reproductibles dans les canaux de test et Trac de WordPress avec les détails d’environnement, puis retester les versions beta et release candidate suivantes. Garder le site public sur une version stable prise en charge jusqu’à la sortie finale et la validation de compatibilité.
Ce que les équipes doivent suivre avant décembre
L’annonce Beta 4 constitue un aperçu utile, pas une spécification définitive. Les auteurs de thèmes et extensions doivent suivre les API concernées ; les responsables de sites peuvent repérer les blocs personnalisés, processus de traduction et besoins d’accessibilité de l’administration à tester. À l’approche de décembre, vérifier le calendrier et le périmètre, susceptibles d’évoluer.
Le guide précédent résume le cycle 7.2 dans son ensemble. La distinction essentielle reste simple : les versions beta aident la communauté à trouver des problèmes ; la production demande une version stable et une procédure de récupération testée. Ne pas mettre à niveau un site actif vers Beta 4.
Sources et références
Une erreur factuelle à signaler ou une source à suggérer ? Contacter la rédaction.
