# WordPress 6.9 et l’éditeur de site : les nouveautés pour les développeurs

> Loin de l'Abilities API qui a capté l'attention, la 6.9 continue de resserrer l'éditeur de site sur des irritants connus : verrouillage, révisions et cohérence des vues.

- Auteur : Clément Hadrot
- Publié le : 2025-12-08
- Mis à jour le : 2025-12-08
- Catégorie : FSE
- URL : https://wpmoderne.dev.wordpress-developpement.fr/fse/wordpress-69-editeur-site-nouveautes-developpeurs/

## L’essentiel

- Un verrouillage de blocs plus granulaire, jusqu'au niveau des réglages individuels
- Les révisions de templates gagnent en lisibilité
- Vigilance à garder sur les thèmes hérités avant de mettre à jour

Chaque nouvelle version majeure de WordPress ravive la même question sur les projets en cours : faut-il mettre à jour tout de suite, ou attendre que les premiers retours de terrain confirment l'absence de régression sur les thèmes blocs existants ? Pour la 6.9, la réponse tient en un mot : consolidation. Rien qui bouleverse un projet en production, mais plusieurs ajustements qui méritent d'être connus avant la mise à jour d'un thème sur mesure.

## Un verrouillage de blocs plus granulaire

Le verrouillage d'un bloc, jusqu'ici limité à deux options globales — empêcher le déplacement, empêcher la suppression — s'affine pour distinguer plus précisément ce qui reste modifiable. Sur un bloc Groupe verrouillé, il devient possible d'autoriser la modification du contenu texte tout en bloquant toute intervention sur les réglages de mise en page ou de couleur, sans devoir choisir entre un verrouillage total et une liberté totale comme c'était le cas jusque-là.

Pour une agence qui livre des templates à des équipes éditoriales peu techniques, ce niveau de granularité réduit le nombre de cas où un verrouillage trop strict empêchait une modification pourtant légitime — un compromis qui, avant cette version, tranchait souvent en défaveur de la flexibilité par excès de prudence.

> L'essentiel à retenir : Un verrouillage de blocs plus granulaire, jusqu'au niveau des réglages individuels ; Les révisions de templates gagnent en lisibilité ; Vigilance à garder sur les thèmes hérités avant de mettre à jour

## Des révisions de templates plus lisibles

L'historique des révisions, disponible sur les templates et template parts depuis la 6.5, gagne en lisibilité : chaque entrée de la liste affiche désormais un résumé synthétique de ce qui a changé (nombre de blocs ajoutés, supprimés ou modifiés) plutôt qu'un simple horodatage accompagné d'un aperçu visuel à comparer soi-même. Cela ne remplace pas un vrai différentiel détaillé, mais aide à repérer plus vite, dans une longue liste de révisions, celle qui correspond réellement à la modification recherchée.

## Points de vigilance avant de mettre à jour un thème existant

- Un thème qui s'appuyait sur le comportement précédent du verrouillage global de bloc doit être revérifié : le nouveau réglage granulaire peut modifier l'expérience par défaut proposée à l'équipe éditoriale sur des blocs déjà verrouillés.
- Les extensions tierces qui interagissent avec l'historique de révisions (sauvegarde externe, journal d'audit) doivent être testées avec le nouveau format de résumé, au cas où elles analysent le contenu brut des révisions plutôt que de se contenter de l'affichage natif.

## Ce que la 6.9 ne change pas côté éditeur de site

Les mécanismes fondamentaux posés depuis les versions précédentes — hiérarchie de templates, pattern overrides, vues de données, Style Book — restent inchangés dans leur fonctionnement. Cette version ne redéfinit aucun de ces piliers ; elle en polit les aspérités identifiées après plusieurs années d'usage réel sur des projets de tailles très diverses.

### Comment tester le nouveau verrouillage sans risque

Sur un projet déjà en production, la prudence consiste à ne pas réactiver en masse le verrouillage existant en espérant profiter automatiquement de la granularité nouvelle : un bloc verrouillé avant la mise à jour conserve son comportement d'origine tant que personne ne rouvre explicitement son panneau de verrouillage pour ajuster les nouvelles options. Il vaut mieux choisir un template peu fréquenté, y appliquer le nouveau réglage fin, observer le comportement obtenu avec un compte au rôle Éditeur, puis généraliser progressivement une fois le comportement validé sur ce cas isolé.

Pour une équipe qui gère plusieurs thèmes clients, cette granularité nouvelle mérite aussi d'être documentée dans les livrables de fin de projet : un client qui découvre, des mois après la mise à jour, qu'il peut désormais modifier un texte auparavant verrouillé sans en comprendre la raison risque de s'inquiéter d'un comportement qu'il perçoit, à tort, comme une régression de sécurité plutôt que comme une amélioration de flexibilité.

## Notre verdict

Trois ans après l'introduction de l'éditeur de site en version stable, ce type de version incrémentale confirme une trajectoire : l'essentiel des grandes briques est posé, et les efforts se concentrent désormais sur les détails qui, accumulés, déterminent si l'outil reste agréable à utiliser au quotidien pour une équipe éditoriale non technique. Le verrouillage granulaire de blocs, en particulier, est la nouveauté à tester en priorité sur tout projet livré à des mains autres que celles du développeur.
