Passer de 6.x à 7.0 impressionne toujours plus que ne le justifie, en réalité, l’ampleur des changements. Le versionnage de WordPress ne suit pas une logique de rupture d’API à chaque chiffre majeur : la 7.0 poursuit, sur l’éditeur de site, la même trajectoire de consolidation amorcée depuis plusieurs versions, sans rien casser de ce qui fonctionnait dans un thème bloc bien construit.
Ce qui progresse réellement
| Domaine | Ce qui change en 7.0 | Impact pour un thème en production |
|---|---|---|
| Styles de section | Applicables à davantage de types de blocs qu’auparavant | Élargit les possibilités de mise en page alternée sans nouveau code |
| Vues de données | Comportement unifié étendu à de nouveaux écrans d’administration | Cohérence accrue, sans changement de structure de données sous-jacente |
| Compatibilité thèmes classiques | Prise en charge partielle maintenue, sans date de retrait annoncée | Aucune migration forcée à prévoir dans l’immédiat |
Styles de section : une portée élargie, pas un nouveau mécanisme
Les styles de section, qui permettaient déjà d’appliquer une apparence nommée à une portion précise d’une page sans toucher à la structure des blocs, couvrent en 7.0 un périmètre de blocs plus large qu’auparavant. Le principe reste identique à celui posé dans les versions précédentes : un style s’applique localement, sans modifier la variation de style globale du site ni le contenu des blocs concernés.
Ce qu’il faut vérifier avant de basculer un site en production
- Rejouer le parcours complet de l’éditeur de site sur un environnement de recette avant toute mise à jour en production, en particulier sur les templates les plus visités du site (page d’accueil, fiche article, archive principale).
- Vérifier que les extensions de blocs tierces installées déclarent une compatibilité explicite avec cette version, plutôt que de présumer qu’une absence d’avertissement suffit à garantir un bon fonctionnement.
- Contrôler que le CSS additionnel hérité, s’il en reste sur le projet, continue de s’appliquer comme attendu — ce mécanisme plus ancien reste actif indépendamment des évolutions de l’éditeur de site.
- Réexporter le thème après la mise à jour si des ajustements de styles de section sont adoptés, pour que les fichiers versionnés reflètent l’état réellement actif du site.
Ce qui ne change pas, et qu’il est utile de rappeler
- La hiérarchie de résolution des templates reste identique à celle en place depuis l’introduction du format de thème bloc.
- Le fonctionnement des patterns synchronisés et des pattern overrides ne subit aucune modification de comportement dans cette version.
- Les capacités qui conditionnent l’accès à l’éditeur de site (
edit_theme_optionsen tête) restent les mêmes qu’auparavant. - Le format des fichiers de thème (
templates/*.html,parts/*.html,theme.json) reste lisible et éditable exactement comme avant, sans nouvelle syntaxe à apprendre pour maintenir un thème existant.
Pourquoi cette stabilité compte autant que les nouveautés elles-mêmes
Sur un thème bloc développé il y a plusieurs années, cette continuité rassure autant qu’elle simplifie le travail de maintenance : un projet qui suivait déjà les bonnes pratiques de structuration (patterns bien catégorisés, template parts cohérentes, styles centralisés dans theme.json) n’a, dans les faits, aucune raison de connaître une régression du seul fait du passage à la 7.0. Les retours de terrain sur les précédents changements de version majeure avaient déjà montré ce schéma : les projets qui rencontrent des difficultés sont presque toujours ceux qui accumulaient déjà, avant la mise à jour, des personnalisations bricolées en dehors des mécanismes prévus par l’éditeur de site.
Un changement de chiffre majeur mérite une phase de recette sérieuse, pas par crainte d’une rupture technique annoncée, mais parce que c’est précisément le moment où les équipes relâchent le plus facilement leur vigilance habituelle, présumant à tort qu’un si gros numéro de version implique forcément un gros risque déjà anticipé par tout le monde.
Notre verdict
La 7.0 confirme que l’éditeur de site a atteint une forme de maturité : les nouveautés se mesurent désormais en extensions de périmètre de mécanismes déjà connus (styles de section, vues de données) plutôt qu’en concepts entièrement inédits à apprendre. Pour une agence gérant plusieurs thèmes en production, le travail de vérification avant mise à jour reste néanmoins identique à celui de toute version majeure : tester avant de déployer, sans se laisser impressionner ni rassurer par le seul changement de numéro.
