WordPress 7.0 : anticiper le nouveau moteur de rendu

WordPress 7.0 s’annonce comme une mise à jour qui va vraiment changer la donne pour nous, développeurs de thèmes et de plugins. Le nouveau moteur de rendu natif, qui abandonne la dépendance à React pour Gutenberg, représente une rupture technique sérieuse — et autant anticiper maintenant plutôt que de se retrouver à gérer des régressions en production. Dans cet article, on fait le tour de ce qui change concrètement et surtout de ce qu’il faut mettre en place dès aujourd’hui pour être prêt.

WordPress 7.0 et le nouveau moteur de rendu : ce qui change vraiment

Avant d’entrer dans le vif du sujet, posons les bases. WordPress 7.0 n’est pas une simple mise à jour incrémentale. C’est une refonte en profondeur de la façon dont WordPress construit et affiche vos pages. Et pour bien comprendre ce qui arrive, il faut d’abord comprendre pourquoi l’ancien système atteignait ses limites.

Pourquoi ce moteur de rendu est une rupture majeure

L’équipe Core a pris une décision radicale : abandonner la dépendance à React comme couche de rendu principale pour Gutenberg, au profit d’un moteur natif WordPress. Ce n’est pas un choix anodin. Depuis l’introduction de Gutenberg en 2018, le rendering engine reposait largement sur React — ce qui apportait une certaine puissance, mais aussi un lot de problèmes bien connus.

Le principal reproche ? La réconciliation du DOM (le mécanisme par lequel React compare l’état virtuel et le DOM réel pour appliquer les changements) générait des surcharges significatives, surtout sur des pages riches en blocs imbriqués. Sur des sites complexes, ça se traduisait concrètement par des temps de rendu côté client plus longs, des scores Core Web Vitals en souffrance, et une expérience éditeur parfois saccadée.

Bref : le moteur montrait ses limites. L’équipe Core a décidé de prendre le problème à la racine.

Ce que le nouveau pipeline de rendu modifie concrètement

Pour faire simple : pensez au pipeline de rendu comme à une chaîne de montage. Avant, une partie de cette chaîne tournait côté client (dans le navigateur de l’utilisateur), l’autre côté serveur — et les deux ne se parlaient pas toujours très bien. Résultat : des duplications de travail, des problèmes d’hydratation des blocs (block hydration) et une Interactivity API qui devait compenser les lacunes de coordination entre les deux environnements.

Avec WordPress 7.0, le pipeline est repensé de fond en comble :

Le server-side rendering (SSR) devient le mode par défaut pour la majorité des blocs
L’Interactivity API est intégrée nativement au moteur, sans passer par React
La block hydration est désormais sélective : seuls les blocs qui ont besoin d’interactivité côté client sont hydratés, pas toute la page
Le moteur natif WordPress gère directement la réconciliation, avec un algorithme bien plus léger que celui de React pour les cas d’usage courants

C’est un changement de paradigme. On passe d’un modèle « tout client » hérité de l’ère des Single Page Applications, à une approche hybride et pragmatique, beaucoup plus adaptée à la réalité des sites WordPress.

Les différences avec le rendu actuel (WordPress 6.x)

En WordPress 6.x, le rendu d’un bloc suit un chemin bien précis : le PHP génère le HTML initial, puis React prend le relais côté client pour gérer les interactions et les mises à jour dynamiques. Ce modèle fonctionne — mais il implique de charger React pour chaque page, même quand il n’y a aucune interaction dynamique réelle. C’est un peu comme déployer une armée entière pour garder une porte.

Avec WordPress 7.0, la logique s’inverse. Le moteur natif assure le rendu par défaut, et React n’intervient plus que dans des contextes très spécifiques (compatibilité avec des plugins tiers qui en dépendent encore, par exemple). Côté performances, les premiers benchmarks internes montrent des gains notables sur le LCP (Largest Contentful Paint) et le TBT (Total Blocking Time).

Pour les développeurs habitués à WordPress 6.x, cette section pose une évidence : les méthodes de développement de blocs vont devoir évoluer. Les sections suivantes détaillent exactement comment.

Ce que les développeurs doivent anticiper dès maintenant

Soyons directs : si vous ne faites rien d’ici la sortie de WordPress 7.0, vous allez vous retrouver avec des thèmes cassés, des plugins qui plantent silencieusement, et des clients qui vous appellent un lundi matin. Ce n’est pas du catastrophisme — c’est simplement ce qui arrive à chaque rupture de moteur de rendu quand on ne prépare pas le terrain en avance.

1. La compatibilité des thèmes et plugins existants — identifiez les patterns à risque

Le premier chantier, c’est l’audit. Et il y a trois grandes catégories de code qui vont potentiellement casser avec le nouveau moteur.

D’abord, les manipulations directes du DOM. Si votre plugin ou votre thème child utilise du JavaScript pour cibler des nœuds Gutenberg via document.querySelector() ou des sélecteurs CSS couplés à des classes générées dynamiquement par React, vous avez un problème. Le nouveau moteur de rendu ne garantit plus les mêmes structures HTML en sortie — certains wrappers disparaissent, d’autres changent de balise sémantique.

Ensuite, les scripts enqueués de façon non standard. L’usage de wp_enqueue_script() avec des dépendances déclarées à la main sur wp-element ou react directement (sans passer par le système de modules natif de WordPress) va poser des conflits. Le moteur 7.0 embarque ses propres primitives de réactivité — charger React en parallèle, c’est la recette pour des bugs impossibles à diagnostiquer.

Enfin, les dépendances React instanciées manuellement. Certain plugins instancient un ReactDOM.render() ou createRoot() dans leurs propres blocs sans s’appuyer sur l’abstraction WordPress. Avec la migration vers le nouveau pipeline, ces instanciations risquent d’entrer en conflit avec le cycle de vie interne du moteur. À identifier et à réécrire.

2. L’Interactivity API : adoptez-la maintenant, pas dans six mois

L’Interactivity API existe depuis WordPress 6.5. Beaucoup de développeurs l’ont regardée de loin en se disant « on verra plus tard ». Mauvaise idée. Avec WordPress 7.0, elle devient le standard officiel pour gérer l’état côté client dans les blocs. Ce n’est plus une option parmi d’autres — c’est le chemin.

Si vous avez des blocs dynamiques qui gèrent de l’interactivité via du JavaScript custom (menus déroulants, filtres Ajax, accordéons), commencez dès maintenant à les réécrire avec wp-interactive, wp-context et wp-bind. La courbe d’apprentissage est modérée, la documentation officielle est solide, et les gains en maintenabilité sont réels. Et surtout : vous serez prêt le jour J.

3. Révision des hooks de rendu côté serveur

Le nouveau moteur SSR-first change le comportement de certains hooks que vous utilisez probablement tous les jours. render_callback dans register_block_type() est concerné : l’ordre d’exécution et le contexte dans lequel il est appelé peuvent varier selon que le bloc est hydraté ou non côté client. Même chose pour get_block_wrapper_attributes() — les attributs générés peuvent différer selon le mode de rendu actif.

Concrètement : passez en revue tous vos register_block_type() et vérifiez que vos render_callback ne font pas d’hypothèses sur le contexte d’exécution (session, cookies, globals PHP). Ce genre de code fonctionne parfaitement aujourd’hui mais peut se comporter de façon imprévisible avec un pipeline de rendu asynchrone ou fragmenté.

4. Tests de régression sur les blocs dynamiques — ne sous-estimez pas ce point

Les blocs dynamiques sont les plus exposés. Pourquoi ? Parce qu’ils dépendent à la fois du rendu serveur et de l’hydratation côté client. C’est exactement là que le nouveau moteur introduit le plus de changements.

Mettez en place une suite de tests de régression si ce n’est pas déjà fait. Concrètement :

Query Monitor est votre premier allié pour détecter les requêtes inattendues, les hooks qui ne se déclenchent plus au bon moment, ou les erreurs PHP silencieuses dans les callbacks de rendu.
WP-CLI vous permet d’automatiser des exports de rendu HTML de vos blocs avant/après migration, et de comparer les sorties via un simple diff.
Les suites de tests unitaires (wp-scripts test-unit-php, Jest pour le JS) doivent couvrir a minima les render_callback de vos blocs dynamiques critiques. Si vous n’avez pas de tests aujourd’hui, c’est le moment d’en écrire, même basiques.

Ne testez pas uniquement en environnement local. Montez un staging qui tourne sur une RC de WordPress 7.0 et passez vos thèmes et plugins dessus. Les surprises arrivent toujours là où on ne les attend pas.

5. Suivez les tickets Trac et les release candidates — c’est non négociable

La sortie de WordPress 7.0 sera précédée de plusieurs beta et d’au moins deux RC (release candidates). C’est pendant cette période que les breaking changes sont documentés, que les dépréciations sont annoncées, et que la communauté remonte les incompatibilités connues.

Concrètement, voici ce que je vous recommande de faire dès maintenant :

Bookmarkez le milestone WordPress 7.0 sur core.trac.wordpress.org et filtrez les tickets tagués rendering-engine ou block-editor.
Abonnez-vous au blog make.wordpress.org/core — les notes de développement (dev notes) publiées avant chaque release détaillent exactement les changements d’API qui vous concernent.
Rejoignez le canal #core-editor sur le Slack WordPress.org si vous ne l’avez pas encore fait.

La bonne nouvelle, c’est que WordPress anticipe toujours ces ruptures avec des périodes de dépréciation. Mais encore faut-il être dans la boucle pour en profiter. Donc : activez les notifications, lisez les RC notes, et testez tôt. C’est le seul moyen de ne pas subir la mise à jour.

Préparer son environnement de dev pour WordPress 7.0

Maintenant qu’on a identifié les chantiers prioritaires, passons à la pratique. Avant de toucher à votre site de production (ou même de staging), il faut un environnement de test dédié et bien configuré. Bonne nouvelle : les outils disponibles aujourd’hui rendent ça vraiment accessible.

Mettre en place un environnement de test dédié

L’option la plus simple et la plus recommandée, c’est @wordpress/env (alias wp-env). Ce package npm officiel spin up un environnement WordPress complet via Docker en quelques commandes. Pas besoin de configurer Apache, MySQL ou PHP à la main :

npm install -g @wordpress/env
wp-env start

Et voilà — WordPress tourne en local sur http://localhost:8888. Pour cibler spécifiquement WordPress 7.0 (ou une bêta), vous pouvez configurer la version dans votre fichier .wp-env.json :

{
  "core": "WordPress/WordPress#7.0-beta1",
  "plugins": ["."]
}

Si vous préférez une interface graphique, LocalWP reste une excellente alternative, surtout pour les équipes mixtes (dev + designers). Et si vous avez déjà une stack Docker maison, vous pouvez bien sûr l’adapter — mais wp-env vous fera gagner un temps fou.

Une fois l’environnement démarré, pensez à activer le thème et les plugins à tester via WP-CLI :

wp-env run cli wp plugin activate mon-plugin
wp-env run cli wp theme activate mon-theme

Adapter ses blocs et thèmes au nouveau moteur

C’est là que le vrai travail commence. Avec le nouveau moteur de rendu, plusieurs points de migration méritent une attention prioritaire.

Le block.json d’abord. Vérifiez que vos attributs sont bien déclarés et que les propriétés dépréciées (certains champs supports de l’ère Gutenberg classique) sont mises à jour. Le nouveau moteur est beaucoup plus strict sur la cohérence entre block.json et l’implémentation réelle.

Les render.php des blocs dynamiques ensuite. Le pipeline SSR-first de WordPress 7.0 va solliciter ces fichiers différemment — notamment en termes d’ordre d’exécution et de contexte disponible. Revoyez vos render.php pour vous assurer qu’ils ne dépendent pas d’états globaux instables.

L’Interactivity API, enfin. Si vous avez commencé à utiliser les directives (wp-bind, wp-context, wp-on), testez-les systématiquement dans votre environnement 7.0. Les comportements d’hydratation sélective peuvent introduire des surprises, notamment sur des blocs imbriqués ou des interactions complexes.

// Exemple : vérifier que wp-context est bien passé au rendu serveur
<div
  data-wp-interactive="mon-bloc"
  data-wp-context='<?php echo wp_json_encode(["isOpen" => false]); ?>'
  data-wp-bind--class="context.isOpen ? 'ouvert' : 'ferme'"
>

Bref, ne survolez pas cette étape. Un bloc qui semblait fonctionner parfaitement en 6.x peut se comporter très différemment avec le nouveau pipeline.

Ressources officielles et communauté à suivre

Pas besoin de faire cavalier seul — la communauté WordPress est très active sur ce sujet. Voici les sources à avoir dans vos favoris dès maintenant :

Make WordPress Core : c’est ici que les décisions architecturales sont annoncées et discutées. Abonnez-vous aux posts taggés 7.0 et rendering.
Dépôt GitHub Gutenberg : suivez les issues et les PRs liées au nouveau moteur. Les changelogs des versions gutenberg plugin sont souvent en avance sur core.
Slack #core-editor (sur le Slack WordPress.org) : l’endroit idéal pour poser des questions directement aux contributeurs. L’ambiance est accueillante, même pour les débutants.
Les changelogs des bêtas WordPress 7.0 : lisez-les vraiment, pas juste en diagonale. Chaque bêta apporte des précisions importantes sur les breaking changes.

Et surtout : contribuez aux tests de la bêta ! Même si vous n’êtes pas contributeur core, tester vos propres plugins et thèmes sur la bêta et remonter les bugs via Trac, c’est une contribution précieuse. Plus les retours arrivent tôt, plus les correctifs peuvent être intégrés avant la release finale. C’est gagnant pour tout le monde.