Advanced Custom Fields dans l’éditeur atomique d’Elementor V4 : ce qui casse

« Champ dynamique introuvable » : c’est le message qui apparaît dans l’inspecteur de l’éditeur atomique d’Elementor V4 quand on tente d’y insérer un champ ACF qui fonctionnait sans problème dans un widget classique Elementor 3.x quelques semaines plus tôt. Le champ existe bien, sa valeur est correctement enregistrée en base : c’est le mécanisme de liaison entre l’éditeur et la donnée qui a changé de fondations.

Elementor V4, annoncé et déployé progressivement depuis 2025, introduit des éléments atomiques : des blocs de rendu plus légers, sans la couche de widgets PHP classique, pensés pour s’intégrer plus nettement avec l’éditeur de site natif de WordPress. Ce diagnostic couvre uniquement ce qui touche à l’affichage de champs ACF dans ces éléments ; il ne traite pas les classes globales de la V4, sujet distinct déjà abordé séparément.

Symptôme : le champ dynamique ne s’affiche pas

Un champ ACF de type texte, image ou repeater, ajouté à un widget Elementor classique via l’option « contenu dynamique », se comportait comme suit sous Elementor 3.x : le widget appelait acf_get_field() depuis son propre rendu PHP, sans intervention supplémentaire. Dans un élément atomique de la V4, cette liaison directe côté PHP a disparu : les éléments atomiques attendent une donnée fournie via un système de props sérialisées, similaire à ce qu’utilisent les blocs Gutenberg natifs.

Diagnostic : deux mécanismes de rendu qui ne se parlent pas

Le widget Elementor classique reste un objet PHP qui génère son HTML à l’appel de render(), avec un accès direct aux fonctions de n’importe quel plugin actif, ACF compris. L’élément atomique fonctionne différemment : il définit un schéma de props typées, résolu côté éditeur, puis transmis au rendu final via une structure de données propre à Elementor. Un appel direct à get_field() dans un contexte d’élément atomique s’exécute bien techniquement, mais en dehors du cycle de rafraîchissement de l’éditeur, ce qui explique pourquoi la valeur affichée en aperçu ne se met pas à jour quand on change de contenu ACF sans recharger la page.

Correctif : exposer le champ via un fournisseur de données

La solution qui fonctionne à ce stade consiste à enregistrer un fournisseur de données dynamique compatible avec le système de props des éléments atomiques, plutôt que d’appeler ACF directement depuis le rendu :

add_filter( 'elementor/atomic/dynamic_data_providers', function( $fournisseurs ) {
    $fournisseurs['acf_champ_texte'] = [
        'label' => __( 'Champ ACF', 'mon-extension' ),
        'resolve' => function( $contexte ) {
            $nom_champ = $contexte['field_name'] ?? '';
            return get_field( $nom_champ, $contexte['post_id'] ?? get_the_ID() );
        },
    ];
    return $fournisseurs;
} );

Ce fournisseur permet à l’élément atomique de résoudre la valeur du champ au moment du rendu, en respectant le cycle de rafraîchissement de l’éditeur, y compris en aperçu avant publication.

Le cas particulier du champ Repeater

Un champ ACF de type Repeater, qui produisait une simple boucle have_rows() dans un widget classique, ne se transpose pas directement dans un élément atomique unique : la V4 attend que chaque ligne du repeater soit rendue comme un élément enfant répété, pas comme du contenu concaténé dans un seul bloc. Concrètement, il faut enregistrer un élément atomique « ligne de repeater » distinct, instancié dynamiquement pour chaque entrée, plutôt que de tenter de tout afficher depuis un unique fournisseur de données.

Ce qui reste inchangé

Les widgets Elementor classiques continuent de fonctionner normalement dans les pages qui ne migrent pas vers les éléments atomiques : Elementor V4 maintient les deux systèmes en parallèle, sans obligation de migration immédiate. Une extension qui embarque des widgets ACF personnalisés peut donc continuer à cibler exclusivement les widgets classiques tant que ses clients n’ont pas basculé leurs pages vers les nouveaux éléments.

Le piège n’est pas que le champ ACF cesse de fonctionner : c’est qu’il fonctionne à moitié, avec une valeur enregistrée correctement mais un aperçu qui ne se met jamais à jour tant qu’on n’a pas migré vers le bon mécanisme de liaison.

Prévention pour les prochaines montées de version

• Isoler tout appel direct à get_field() ou have_rows() dans une couche d’accès dédiée, jamais dispersé dans le rendu.
• Tester chaque widget ACF personnalisé dans les deux modes, classique et atomique, avant chaque montée de version majeure d’Elementor.
• Suivre le journal des modifications d’Elementor sur son dépôt officiel pour anticiper l’ajout de nouveaux points d’extension aux éléments atomiques.

En résumé

Un champ ACF qui disparaît silencieusement dans un élément atomique Elementor V4 n’est presque jamais un bug d’ACF : c’est un widget classique qui appelait directement une fonction PHP là où la V4 attend un fournisseur de données déclaré. Le correctif tient en quelques dizaines de lignes, à condition de comprendre que les deux systèmes de rendu ne partagent pas le même cycle de vie.