La version est encore en développement
Au 15 octobre, le calendrier officiel prévoit WordPress 7.2 Beta 1 le 20 octobre à 15 h UTC, puis une version finale le 8 décembre. Ce sont les objectifs actuels du projet, pas une garantie que les dates ou le périmètre ne changeront pas. L’équipe prévoit que 7.2 soit la dernière version majeure de 2026 et qu’un nouveau thème par défaut l’accompagne.
Pour les responsables de sites, il est temps de préparer un environnement de test, pas une mise à jour de production. Le développement continue avant Beta 1 ; les versions bêta et candidates servent à trouver des problèmes, pas à faire tourner des sites publics ordinaires. Suivez la page de la release et les notes développeur avant de décider de la mise à jour stable.
Un changement de compatibilité SQL est documenté
Une note de développement décrit déjà un changement concret : WordPress 7.2 considère le mode MySQL `NO_BACKSLASH_ESCAPES` comme non pris en charge et le retire des modes de session à la connexion. WordPress utilise l’antislash pour échapper certains caractères dans les requêtes SQL ; avec ce mode, la base l’interprète autrement. La modification concerne la session WordPress, pas la configuration globale du serveur.
L’équipe Core indique que la plupart des sites ne verront pas de différence, mais qu’un site peut mal fonctionner si le mode reste actif. Une installation qui en dépend volontairement doit être revue par un développeur. Le filtre documenté doit être chargé avant les extensions classiques, car la connexion à la base intervient plus tôt. Il ne faut pas modifier les réglages SQL de tous les serveurs par réflexe.
Une version Gutenberg n’est pas une promesse pour Core
Gutenberg suit son propre calendrier et ses notes peuvent inclure des travaux qui ne feront pas nécessairement partie d’une version précise du cœur WordPress. La feuille de route 7.2 mentionne un nouveau thème et indique que les fonctionnalités seront retenues lorsqu’elles seront suffisamment prêtes ; elle ne constitue pas une liste figée des changements éditeur. Les notes bêta et le guide final seront les références pour thèmes et extensions.
La bonne question pour une agence est de savoir quel code figure réellement dans la bêta puis la version finale de 7.2. Comparez la build avec les extensions, le thème, les blocs personnalisés, PHP, l’hébergement et les outils d’édition utilisés par chaque client. Testez le site réel plutôt que de vous fier uniquement à un badge de compatibilité.
Une préparation prudente en quatre étapes
Créez une copie de staging avec des sauvegardes récentes et une restauration testée. Notez les versions de WordPress, PHP, base et extensions, ainsi que le code qui modifie SQL ou l’éditeur. Quand Beta 1 paraîtra, testez un site représentatif : édition, publication, modèles, tâches planifiées, formulaires, paiements ou adhésions et journaux.
Laissez la production sur une version stable prise en charge jusqu’à la sortie finale et à la réussite de vos tests. Pendant la bêta, signalez des problèmes reproductibles avec les détails de l’environnement. Après la sortie, mettez d’abord à jour le staging, vérifiez sauvegarde et retour arrière, puis planifiez la production selon le risque et la maintenance du site. Ne promettez pas une compatibilité avant validation.
Sources et références
Une erreur factuelle à signaler ou une source à suggérer ? Contacter la rédaction.
