WordPress 7.0 pour les développeurs de blocs : ce qui change

WordPress 7.0 marque le passage à un nouveau cycle de numérotation majeure pour le projet, après la série des versions 6.x entamée en 2020 avec la 6.0. Passé l’aspect symbolique du changement de chiffre, cette version se présente surtout comme une consolidation des grandes API de blocs stabilisées ces dernières années — Interactivity API, block bindings, block hooks — plutôt que comme une nouvelle vague de fonctionnalités inédites pour les développeurs de blocs.

Ce tour d’horizon reste circonscrit aux changements qui concernent réellement le développement et la maintenance de blocs personnalisés, sans couvrir les nouveautés côté fonctionnalités d’intelligence artificielle annoncées par ailleurs pour cette version, hors du périmètre de cet article.

Consolidation de l’Interactivity API

Plusieurs directives de l’Interactivity API, jusque-là marquées comme sujettes à changement dans la documentation officielle, obtiennent un statut stable dans cette version, avec une garantie de rétrocompatibilité renforcée pour les versions suivantes. Les développeurs qui avaient déjà adopté ces directives (data-wp-router-region, les sources de binding personnalisées) n’ont aucun changement de syntaxe à opérer ; il s’agit essentiellement d’un engagement de stabilité à long terme plutôt que d’une modification technique.

Ajustements sur les block bindings

L’interface d’édition des bindings, introduite progressivement depuis la 6.7, gagne une meilleure prise en charge des sources de binding personnalisées dans le panneau latéral, avec un affichage plus clair de la source active sur un attribut donné. Côté API PHP, register_block_bindings_source() ne change pas de signature, mais accepte un nouvel argument optionnel pour préciser une icône affichée dans l’interface de sélection de source, purement cosmétique et sans impact sur le comportement fonctionnel existant.

register_block_bindings_source( 'agence/champ-personnalise', array(
    'label'              => __( 'Champ personnalisé agence', 'agence' ),
    'icon'               => 'admin-generic',
    'get_value_callback' => 'agence_recuperer_valeur_champ',
) );

Ce qui a été retiré ou finalement déprécié

Après plusieurs versions d’avertissement progressif entamées dès la 6.8, la syntaxe de filtre render_block à deux arguments (sans l’objet WP_Block en troisième paramètre) déclenche désormais une erreur de dépréciation plus visible en mode débogage, sans encore de suppression complète du support. Les extensions qui n’ont pas encore migré vers la signature à trois arguments doivent prévoir cette mise à jour avant la suppression définitive annoncée pour une version ultérieure.

// À corriger si ce n'est pas déjà fait depuis la 6.8
add_filter( 'render_block', function ( $contenu, $bloc_array, $instance ) {
    return $contenu;
}, 10, 3 );

Checklist de tests avant mise à jour

• Vérifier que tous les filtres render_block personnalisés utilisent la signature à trois arguments avec l’objet WP_Block.
• Tester l’affichage du panneau d’édition des bindings sur les sources personnalisées du projet, en particulier si un nouvel argument icon a été ajouté ou non.
• Confirmer qu’aucun avertissement de dépréciation nouveau n’apparaît en mode WP_DEBUG sur les blocs existants après activation de la mise à jour sur un environnement de recette.
• Repasser une revue rapide des blocs qui utilisent le router de l’Interactivity API, pour profiter de la stabilité renforcée désormais garantie sur ces directives.

Ce qui reste identique

L’enregistrement de base d’un bloc (register_block_type(), block.json, le cycle edit()/save()) ne subit aucune modification dans cette version. Les blocs développés en apiVersion 3 depuis la 6.3 continuent de fonctionner sans adaptation, ce qui confirme la trajectoire de stabilité progressive de l’écosystème de blocs depuis plusieurs versions majeures.

Le constat qu’on tire de cette version, en la comparant aux précédentes : l’écosystème de blocs semble entrer dans une phase de maturité où les changements portent davantage sur la consolidation d’API existantes que sur l’ajout de nouvelles couches. Une bonne nouvelle pour la stabilité à long terme des projets en production.

En résumé

WordPress 7.0 ne bouleverse pas les habitudes de développement de blocs personnalisés : elle stabilise l’Interactivity API, affine l’interface des block bindings, et referme progressivement la porte de l’ancienne signature de filtre render_block à deux arguments. Une mise à jour qui se prépare avec une checklist ciblée plutôt qu’une refonte, pour la grande majorité des extensions déjà maintenues selon les bonnes pratiques des versions précédentes.