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

WordPress 6.7 est sorti le 12 novembre 2024, porté par l’équipe autour du thème Twenty Twenty-Five. Le zoom out de l’éditeur de site, très visible côté utilisateur final, a capté l’essentiel de l’attention médiatique — mais plusieurs changements plus discrets touchent directement le quotidien des développeurs de blocs, sans faire la une. Ce tour d’horizon reste volontairement centré sur ces derniers.

Rien de spectaculaire ici, mais plusieurs API qui simplifient des tâches jusque-là fastidieuses, et une consolidation générale de l’expérience d’édition des block bindings, cette fonctionnalité introduite en 6.5 qui reliait un attribut de bloc à une source de données externe.

Block bindings enfin éditables dans l’interface

Depuis leur introduction en 6.5, les block bindings permettaient de lier un attribut de bloc (le contenu d’un paragraphe, la source d’une image) à un champ personnalisé ou une autre source de données, mais leur configuration restait entièrement dépendante du code : impossible de créer ou modifier un binding directement depuis l’interface de l’éditeur. La 6.7 introduit une interface pour connecter un attribut à un champ personnalisé existant sans écrire une ligne de PHP, via le panneau latéral du bloc concerné.

Pour les développeurs, cela ne change rien à l’API PHP d’enregistrement des sources de binding (toujours register_block_bindings_source()), mais impose de vérifier que les sources personnalisées développées pour un projet exposent correctement leurs libellés (label) et leur capacité d’édition (uses_context, callback set_value) pour apparaître proprement dans cette nouvelle interface.

wp_register_block_metadata_collection

Cette nouvelle fonction permet d’enregistrer en un seul appel un manifeste précompilé des métadonnées de plusieurs blocs, généré via la commande wp-scripts build-blocks-manifest, plutôt que de laisser WordPress lire et décoder chaque block.json individuellement au chargement. Un gain surtout perceptible sur les extensions à nombreux blocs, traité en détail dans un article dédié de ce blog.

wp_register_block_metadata_collection(
    __DIR__ . '/build/blocks',
    __DIR__ . '/build/blocks-manifest.php'
);

Nouvelles API de prévisualisation de bloc

La 6.7 affine le mécanisme de prévisualisation des blocs dans l’inserteur (le survol qui affiche un aperçu miniature avant insertion). Les développeurs de blocs personnalisés peuvent désormais fournir un exemple plus riche via la propriété example de block.json, avec un meilleur support des blocs imbriqués dans cet aperçu — utile pour des blocs conteneurs dont l’aperçu vide ne donnait auparavant qu’une idée limitée du rendu réel.

{
    "example": {
        "attributes": {
            "titre": "Nos points forts"
        },
        "innerBlocks": [
            { "name": "core/paragraph", "attributes": { "content": "Un exemple représentatif." } }
        ]
    }
}

Évolutions de block.json

Plusieurs ajustements mineurs mais utiles sur le schéma de block.json :

• Une meilleure prise en charge de la validation des valeurs par défaut des attributs de type rich-text, évitant certains messages d’avertissement en console auparavant silencieux.
• Des clarifications dans la documentation officielle sur la clé selectors introduite en 6.3, avec des exemples supplémentaires pour les blocs à balisage interne complexe.
• Un support affiné des styles de bloc (styles) pour les variantes qui combinent supports natifs et classes personnalisées.

Dépréciations à surveiller

Aucune dépréciation majeure d’API de blocs n’accompagne cette version, ce qui reste suffisamment rare pour être signalé : les projets utilisant l’apiVersion 3 introduite en 6.3 n’ont rien à corriger pour rester compatibles. La vigilance porte plutôt sur les extensions tierces qui s’appuyaient sur des comportements non documentés de l’ancien système de prévisualisation, potentiellement affectés par les changements internes de rendu de l’aperçu.

Sur nos projets, la migration vers 6.7 s’est faite sans incident sur l’ensemble des blocs personnalisés déjà en apiVersion 3 — la seule vraie action a été de tester le nouveau panneau d’édition des bindings sur les sources personnalisées développées pour deux clients, qui nécessitaient un ajustement mineur du libellé affiché.

Ce que 6.7 ne couvre pas

Le zoom out de l’éditeur, star de cette version côté communication, ne modifie aucune API destinée aux développeurs de blocs individuels : il s’agit d’un changement de navigation dans l’éditeur de site, pas d’un nouveau support ou d’une nouvelle clé de block.json. Les développeurs qui cherchent une checklist de compatibilité de leurs blocs face au zoom out n’ont, à ce stade, rien de spécifique à adapter.

En résumé

WordPress 6.7 consolide plus qu’elle ne révolutionne côté développement de blocs : l’interface d’édition des bindings devient enfin utilisable sans code, le nouveau manifeste de métadonnées accélère l’enregistrement des extensions à nombreux blocs, et la prévisualisation dans l’inserteur gagne en fidélité. Rien qui impose une migration dans l’urgence, mais plusieurs bonnes raisons de revoir les blocs existants pour en tirer parti.