« Fin 2023, l’Interactivity API n’existe encore que sous forme de proposition et de code fusionné dans le cœur de développement, sans garantie de stabilité avant la sortie prévue de WordPress 6.5 au printemps 2024. » Cette phrase, tirée de la feuille de route publiée sur make.wordpress.org, a servi de point de départ à ce chantier : comment préparer un thème bloc pour une fonctionnalité qui n’est pas encore figée ?
La tentation classique est d’attendre la sortie stable pour commencer à tester. Le risque, c’est de découvrir en avril les ruptures d’API qui auraient pu être anticipées dès novembre, avec quatre mois de retard sur la mise en conformité du thème.
Mettre en place un environnement contre les nightlies
Le projet WordPress publie des builds de développement du cœur, en dehors du cycle de version stable. Un second environnement de test, distinct de la CI principale, installe la dernière version du cœur depuis la branche trunk plutôt que depuis un tag figé.
wp core download --version=nightly --force
wp core update-db
Ce job tourne une fois par semaine, pas à chaque commit : la volatilité du cœur en développement produirait trop de faux signaux si on le testait à chaque push.
Marquer les tests comme instables plutôt que les ignorer
PHPUnit propose l’attribut @group pour isoler ces tests dans une suite séparée, appelée bleeding-edge dans le projet. Elle échoue sans bloquer le pipeline principal, mais génère une alerte visible dans le canal de suivi.
/**
* @group bleeding-edge
*/
public function test_data_wp_context_survives_hydration() {
$this->assertMatchesRegularExpression(
'/data-wp-context/',
render_block( $this->get_test_block() )
);
}
Trois tests ont été écrits sur ce principe : la présence de l’attribut data-wp-context dans le rendu, la persistance de l’état côté client après une interaction, et la compatibilité de la directive data-wp-on--click avec le format attendu par le moteur de rendu du thème.
Suivre le ticket de référence plutôt que la documentation
La documentation stable n’existant pas encore, la source de vérité est restée le ticket Trac de la fonctionnalité et les discussions sur le canal Slack Core Editor. Chaque changement d’API constaté a été noté dans un fichier de suivi interne, avec la date et le commit du cœur qui l’a introduit.
Ce que la volatilité a coûté
Sur les huit semaines de suivi, l’attribut de directive a changé de syntaxe une fois, passant d’une notation à double tiret vers une notation différente avant d’être stabilisé. Sans le job dédié, cette évolution serait passée inaperçue jusqu’au jour où le thème aurait cessé de fonctionner sur une version bêta publique de WordPress 6.5.
- Une évolution de syntaxe détectée avant la bêta publique
- Zéro régression silencieuse constatée à ce jour sur les nightlies
- Un thème qui vise à être prêt dès le premier jour de disponibilité de WordPress 6.5
Tester contre une API en mouvement n’apporte pas de garantie définitive, mais transforme une découverte tardive en ajustement anticipé.
Ce que ce dispositif ne couvre pas
Les block bindings, fonctionnalité distincte prévue dans le même cycle de version, font l’objet d’un suivi séparé : les deux API évoluent à des rythmes différents et les mélanger dans la même suite bêta aurait rendu les échecs difficiles à attribuer à la bonne cause.
Pour aller plus loin
Ce dispositif de veille active sera démonté environ deux semaines après la sortie stable de WordPress 6.5, une fois la suite principale mise à jour pour cibler officiellement la nouvelle version minimale. Le job hebdomadaire contre les nightlies sera néanmoins réactivé à chaque nouveau cycle de développement du cœur, dès qu’une fonctionnalité structurante touche le thème.
