# ACF et relations imbriquées : ce que WPML casse encore sur les répéteurs

> Après traduction, les liaisons entre champs répéteurs ACF disparaissent sur un cas précis, non couvert par les guides généraux ACF et WPML déjà publiés.

- Auteur : WordPress Développement
- Publié le : 2021-11-02
- Mis à jour le : 2021-11-02
- Catégorie : Multilingue
- URL : https://www.wpmoderne.fr/multilingue/acf-wpml-repeteurs-relations-imbriquees/

## L’essentiel

- Un champ relation imbriqué dans un répéteur perd sa cible après traduction
- Le problème ne touche pas les champs relation de premier niveau
- Un correctif de synchronisation manuelle referme la brèche

`Array ( [0] => Array ( [entreprise_partenaire] => ) )`. C'est ce que retourne `get_field('partenaires')` sur la version anglaise d'une page fraîchement traduite avec WPML, alors que la version française source affichait correctement le nom et le lien de chaque entreprise partenaire. Le répéteur existe bien, ses trois lignes sont bien là, mais le champ relation imbriqué dans chaque ligne est systématiquement vide.

Ce cas est distinct du problème plus connu et déjà documenté des champs relation simples, de premier niveau, qui eux se synchronisent correctement avec les bons réglages WPML. Ici, le champ relation qui casse est imbriqué à l'intérieur d'un répéteur ACF, une structure à deux niveaux que WPML gère différemment.

## Reproduire le cas précis : un répéteur « partenaires » avec un champ relation par ligne

La structure ACF en cause ressemble à ceci :

```
Groupe de champs "Page partenaire"
└── partenaires (répéteur)
    ├── entreprise_partenaire (relation vers CPT "entreprise")
    ├── role_partenariat (texte libre)
    └── date_debut (date)
```

Le champ `role_partenariat` et `date_debut` se traduisent ou se synchronisent sans problème selon le réglage choisi dans WPML. Seul `entreprise_partenaire`, le champ relation imbriqué dans la ligne du répéteur, perd sa valeur après traduction de la page.

## Cause : WPML traduit l'ID de relation, mais pas dans le bon contexte de répéteur

> L'essentiel à retenir : Un champ relation imbriqué dans un répéteur perd sa cible après traduction ; Le problème ne touche pas les champs relation de premier niveau ; Un correctif de synchronisation manuelle referme la brèche

WPML sait convertir l'ID d'un post référencé par un champ relation vers l'ID de sa traduction correspondante — c'est le mécanisme qui fonctionne pour les champs relation de premier niveau. Sur un champ imbriqué dans un répéteur, cette conversion d'ID s'appuie sur le nom du champ ACF tel qu'enregistré dans la configuration de synchronisation multilingue de WPML, réglages ACF, section « Champs personnalisés traduisibles ».

Le nom technique du champ imbriqué n'est pas simplement `entreprise_partenaire`, mais un chemin complet incluant le nom du répéteur parent. Si WPML n'a été configuré qu'avec le nom court du champ, sans son chemin de répéteur, il ne reconnaît pas la relation à convertir et laisse le champ vide plutôt que de recopier une valeur incorrecte.

## Correctif : déclarer explicitement le champ selon son chemin complet

La correction consiste à aller dans **WPML → Réglages personnalisés des champs**, à repérer la ligne correspondant au champ imbriqué (WPML l'affiche généralement sous une forme du type `partenaires_0_entreprise_partenaire` ou un identifiant équivalent selon la version), et à la définir explicitement comme « Copier » avec conversion de relation, plutôt que « Ne pas traduire » qui est souvent le réglage par défaut appliqué automatiquement aux nouveaux champs détectés dans un répéteur.

```
Réglages ACF multilingues (WPML) :
partenaires                       -> Copier (structure du répéteur)
partenaires > role_partenariat    -> Traduire
partenaires > date_debut          -> Copier
partenaires > entreprise_partenaire -> Copier (relation, conversion ID)
```

Une fois ce réglage appliqué et une nouvelle traduction régénérée (les traductions déjà existantes avant la correction restent cassées et doivent être retraduites ou corrigées manuellement une par une), le champ relation imbriqué recopie correctement l'ID converti vers la traduction de l'entreprise partenaire.

## Vérifier après coup avec une requête directe, pas seulement visuellement

Le piège de ce bug est qu'il peut passer inaperçu si l'affichage front-end masque simplement la ligne vide sans erreur visible. La vérification la plus fiable reste une inspection directe via `get_field()` en mode déboguage, ou une requête WP-CLI sur les métadonnées du post traduit :

```
wp post meta list 1234 --keys=partenaires_0_entreprise_partenaire
```

Si cette commande retourne une valeur vide ou absente sur la traduction alors qu'elle retourne un ID valide sur l'original, la relation imbriquée est cassée et le réglage de synchronisation doit être revu.

## En résumé

Un champ relation imbriqué dans un répéteur ACF ne suit pas automatiquement le même chemin de synchronisation qu'un champ relation de premier niveau dans WPML : il faut le déclarer explicitement selon son chemin complet dans les réglages de champs personnalisés. Sans cette déclaration précise, WPML préfère vider le champ plutôt que de propager une valeur potentiellement incorrecte, ce qui rend le bug silencieux tant que personne ne vérifie le contenu réellement affiché.