ACF PRO 6.8.9 : vos blocs passent en V3 par défaut — les trois cas à vérifier maintenant

Advanced Custom Fields PRO 6.8.9 est disponible. Le changement principal concerne directement tous les développeurs qui maintiennent des blocs ACF : à partir de cette version, tout bloc qui ne déclare pas explicitement sa version, qu'il soit enregistré via block.json ou en PHP avec acf_register_block_type(), sera enregistré comme bloc V3 sur WordPress 7.1 et versions ultérieures.

Si vous avez suivi la sortie de WordPress 7.1 « Mary Lou », vous savez que l'éditeur de blocsÉditeur de blocs de WordPress (et écosystème associé) pour composer pages et contenus. affiche désormais le canevas d'édition dans une iframe par défaut — aussi bien pour les thèmes blocs que pour les thèmes classiques. C'est cette iframe qui rend le mode edit des blocs V2 inopérant, et c'est ce qui a poussé l'équipe ACF à faire de V3 le comportement par défaut.

Avant d'aller plus loin, un point important : le plugin de compatibilité proposé par l'équipe ACF est un pont temporaire, pas une solution pérenne. Certaines fonctionnalités peuvent ne pas fonctionner parfaitement avec ce plugin — ce n'est pas un chemin pleinement supporté. Et à mesure que WordPress core fera évoluer l'éditeur iframé, cette approche de compatibilité pourrait cesser de fonctionner dans une future version.

Pourquoi V2 ne tient plus dans WordPress 7.1

Le mécanisme est direct.

Les blocs V2 s'appuient sur du JavaScript et du CSS chargés côté wp-admin pour faire fonctionner leur interface d'édition — notamment des bibliothèques WordPress comme l'éditeur WYSIWYG et les sélecteurs de date jQuery UIUser Interface : couche visuelle et interactive (composants, layout, états)., que WordPress lui-même ne charge plus à l'intérieur de l'iframe.

L'iframe, utilisée par l'éditeur depuis Blocks APIApplication Programming Interface : contrat machine pour consommer un service (HTTP, SDK, webhooks). v3 dans WordPress 6.3, devient avec WordPress 7.1 le comportement par défaut du canevas d'édition, y compris pour les thèmes classiques. Elle isole ce canevas du reste de l'administration WordPress : seuls les scripts et styles du thème sont chargés à l'intérieur. Les bibliothèques nécessaires au fonctionnement de V2 ne sont donc plus disponibles dans le canevas.

Avant WordPress 7.1, insérer un bloc V2 dans l'éditeur retirait automatiquement l'iframe. Ce n'est plus le cas : l'iframe reste, et le mode edit V2 se retrouve privé de ses dépendances. Les champs sont alors forcés en mode preview et l'édition ne reste accessible que depuis l'étroite sidebar de droite, ce qui devient particulièrement contraignant avec des blocs comportant des Repeater, du Flexible Content ou de nombreux champs.

Le mode edit V2 n'est pas récupérable dans l'éditeur iframé sans contournements qui finiront par cesser de fonctionner. C'est un point que l'équipe ACF elle-même souligne.

Trois cas, trois diagnostics

Cas 1 — Blocs sans version explicite

C'est le scénario le plus courant. Avec ACF PRO 6.8.9, les blocs enregistrés sans version explicite passent par défaut en V3 sur WordPress 7.1 et versions ultérieures, qu'ils soient déclarés via block.json ou enregistrés en PHP avec acf_register_block_type().

Diagnostic : vérifiez les block.json de vos projets, mais aussi les appels à acf_register_block_type() présents dans vos thèmes et plugins. Tout bloc enregistré sans version explicite utilisera V3 par défaut sous WordPress 7.1 et versions ultérieures.

Cas 2 — Blocs avec acf.blockVersion ou acf_block_version explicitement défini à 1 ou 2

Ces blocs ne sont pas concernés par le changement de valeur par défaut : ils continuent d'utiliser la version qu'ils déclarent. S'ils restent en V1 ou V2, ils rencontrent sous WordPress 7.1 le symptôme décrit plus haut : les champs sont forcés en preview et l'édition ne reste accessible que depuis la sidebar de droite.

À noter : les blocs qui déclarent explicitement leur version ne sont pas affectés par le filtre acf/blocks/default_block_version et devront être mis à jour individuellement.

Cas 3 — Besoin de temps avant la migration

L'équipe ACF propose deux leviers pour gérer la transition. Le premier est le plugin de compatibilité officiel — acf-blocks-v2-iframe-compatibility — qui restaure le comportement d'édition V2 sur WordPress 7.1.

Ce plugin est conçu comme un pont temporaire pour donner aux équipes le temps de migrer. Nous insistons : certaines fonctionnalités peuvent ne pas fonctionner parfaitement avec ce plugin, et cette approche pourrait cesser de fonctionner dans une future version de WordPress.

Le second levier est le filtre acf/blocks/default_block_version, qui permet de modifier globalement la version utilisée par défaut pour les blocs qui n'en déclarent aucune. ACF le propose notamment pour conserver temporairement l'ancien défaut. À l'inverse, pour faire basculer en masse les blocs sans version explicite vers V3, le filtre peut être utilisé ainsi :

add_filter( 'acf/blocks/default_block_version', function() {
    return 3;
});

Ce que V3 apporte dans cette release

ACF PRO 6.8.9 inclut aussi des améliorations concrètes pour les blocs V3 :

• Migration automatique des réglages legacy V2 : lorsqu'un bloc V3 combine "mode": "edit" avec "supports": { "mode": false }, ACF saute désormais automatiquement le template de rendu dans l'éditeur et affiche à la place un placeholder avec l'icône du bloc, son titre et un bouton d'édition.
• renderPreview dans block.json : "renderPreview": false permet de demander explicitement ce comportement pour les nouveaux blocs.
• Édition inline sans double clic : les champs éditables inline dans les blocs V3 n'exigent plus un second clic avant de pouvoir être modifiés.

Pour rappel, les blocs V3 nécessitent ACF PRO 6.6 ou ultérieur. L'édition inline en V3 nécessite ACF PRO 6.7 ou ultérieur.

Par défaut, un bloc V3 affiche son preview directement dans le canevas. Un clic sur l'icône crayon ouvre un panneau d'édition étendu à côté de ce preview, avec davantage d'espace que la sidebar utilisée par les blocs V2 sous WordPress 7.1. L'édition inline peut aussi être activée pour permettre de modifier directement les champs texte depuis le preview.

Autres correctifs notables

En dehors des blocs, cette version corrige deux irritants :

• Les boutons radio s'affichent désormais correctement dans les écrans d'administration ACF.
• Les champs Image et Gallery n'empêchent plus l'envoi de fichiers SVG lorsque le plugin Safe SVG est actif.

Le contexte écosystème

Cette mise à jour s'inscrit dans les secousses provoquées par WordPress 7.1 sur l'écosystème des extensions. L'iframe par défaut dans l'éditeur ne touche pas que ACF — l'incident WP Rocket post-7.1 en est un autre exemple concret.

V3 représente un changement significatif pour les éditeurs de contenu : les workflows changent, et une formation est nécessaire. Pour les agences et les freelances qui ont construit des centaines de sites et formé des centaines de clients sur l'expérience d'édition V2, c'est une disruption réelle et significative.

La migration vers V3 n'est pas optionnelle à terme. Le plugin de compatibilité achète du temps, mais la direction est claire.