Guide de dépannage

Cette section couvre les problèmes les plus courants que vous pouvez rencontrer avec Field Forge et comment les résoudre. Pour chaque problème, nous décrivons les symptômes, les causes probables et les solutions étape par étape.

L’aide Tooltip ouvre la page d’accueil au lieu de l’article

Symptômes : Cliquer sur la petite icône d’aide ? dans l’administration de Field Forge ouvre la page d’accueil de Field Forge ou la page d’accueil de la documentation au lieu de l’article spécifique pour ce paramètre. Solution : Mettez à jour Field Forge vers la version actuelle. Les liens d’aide de l’administration dirigent désormais vers les URL exactes de la section du Guide de l’utilisateur ou du Guide du développeur. Si une page d’administration mise en cache a toujours l’ancien lien, rafraîchissez la page une fois.

La désactivation de Forge Suite sur un clone affecte un autre site

Symptômes : Vous avez cloné ou restauré un site WordPress, puis cliqué sur Forge Suite > Désactiver sur le clone. Un autre site utilisant la même licence semble avoir perdu son état PRO ou Connect. Cause : Les anciennes versions faisaient confiance à l’ID d’installation Freemius stocké dans fs_accounts. Une base de données clonée peut porter l’ID d’installation et l’URL du site d’origine, donc même une désactivation Freemius ciblée sur l’installation peut viser l’installation distante d’origine. Solution : Mettez à jour Field Forge vers la dernière version. Forge Suite compare désormais l’URL du site Freemius stockée avec l’URL actuelle de WordPress site_url() / home_url() avant toute désactivation distante. Si l’état appartient à un autre site, il ignore l’appel Freemius distant et ne vide que l’état de la licence locale pour l’installation WordPress actuelle. Reconnectez le clone via Field Forge > Licence > Connecter à Avakode lorsque vous souhaitez qu’il soit à nouveau licencié.

Les champs ne s’affichent pas dans l’éditeur de publication

Symptômes : Vous avez créé un groupe de champs, mais les champs n’apparaissent pas lorsque vous éditez un article ou une page. Causes et solutions possibles :

Les règles de localisation ne correspondent pas à l’article. Ouvrez le groupe de champs et vérifiez la section Règles de localisation. Vérifiez que les conditions correspondent à l’article que vous éditez. Par exemple, si la règle dit “Le type de publication est égal à Produit” mais que vous éditez une Page, les champs n’apparaîtront pas.
Le groupe de champs est défini sur Inactif. Dans la liste des groupes de champs, vérifiez que la colonne Statut indique “Actif”. Si elle indique “Inactif”, ouvrez le groupe de champs et changez son statut.
Un autre plugin cache la metabox. Certains plugins de création de pages ou de nettoyage de l’administration cachent les metaboxes. Vérifiez les Options d’écran (coin supérieur droit de l’écran d’édition) et assurez-vous que votre metabox de groupe de champs est cochée.
Le groupe de champs n’a pas de champs. Un groupe de champs vide avec zéro champ n’affichera pas de metabox. Ouvrez le groupe de champs et ajoutez au moins un champ.
Problème de cache. Si vous venez de créer le groupe de champs, essayez de rafraîchir la page de l’éditeur de publication. Dans certains environnements d’hébergement, la mise en cache des objets peut retarder l’apparition des nouvelles metaboxes.

get_field() retourne null

Symptômes : Votre modèle de thème utilise get_field('field_name') mais il retourne null ou une valeur vide, même si des données ont été saisies dans l’éditeur. Causes et solutions possibles :

Nom de champ incorrect. Le nom passé à get_field() doit correspondre au Nom du champ (slug), pas à l’Étiquette. Ouvrez l’éditeur de groupe de champs et vérifiez la colonne Nom. Par exemple, si l’étiquette est “Titre du héros” mais que le nom est hero_title, utilisez get_field('hero_title').
ID de publication manquant. Si vous appelez get_field() en dehors de la boucle (par exemple, dans un modèle d’en-tête ou de pied de page), vous devez passer explicitement l’ID de la publication : get_field('hero_title', $post_id). Sans le deuxième paramètre, il se réfère à la publication actuelle dans la boucle, qui peut ne pas exister dans votre contexte.
Utilisation des données de la page d’options sans ‘options’. Pour les champs de page d’options, vous devez passer 'options' comme deuxième paramètre : get_field('site_phone', 'options'). Sans cela, Field Forge cherche le champ sur la publication actuelle et ne trouve rien.
Field Forge est désactivé. Si Field Forge n’est pas actif et que votre thème n’a pas de solution de repli, get_field() sera indéfini et provoquera une erreur fatale (ou retournera null si un autre plugin fournit un stub). Vérifiez que Field Forge est activé dans les Plugins.
Les données ont été saisies avec ACF mais non migrées. Si les données ont été initialement enregistrées par ACF et que vous n’avez pas exécuté la migration, les tables de Field Forge seront vides. Allez dans Field Forge > Migration et importez les valeurs.
ACF est actif lors d’un contrôle de page d’options LangForge. Lorsque ACF possède get_field(), Field Forge relie désormais les lectures d’options ACF vides à la même table d’options de Field Forge consciente de la langue utilisée par la couche de compatibilité ACF. Ceci est destiné aux fenêtres de migration/QA où ACF, Field Forge et LangForge sont actifs ensemble.

Les modifications d’un champ à l’intérieur d’un groupe ne sont pas enregistrées

Symptômes : Vous changez une valeur de texte, de zone de texte ou de WYSIWYG qui se trouve à l’intérieur d’un champ de groupe, cliquez sur Mettre à jour, et la valeur revient au contenu précédent lors du rechargement. D’autres champs sur le même article s’enregistrent normalement. Les champs en dehors du groupe s’enregistrent normalement. Pourquoi cela se produit : C’était une régression spécifique aux groupes dont les données ont été importées d’ACF (ou migrées d’un plugin précédent) et donc stockées de manière hiérarchique — le groupe lui-même occupe une ligne dans la table de valeurs de Field Forge et chaque sous-champ est lié par l’ID d’enregistrement du groupe. Les sous-champs du formulaire d’administration dans cette structure ont été soumis sous une clé POST que le gestionnaire de sauvegarde de Field Forge ne lisait pas, donc les modifications des sous-champs étaient silencieusement supprimées. Les groupes qui n’ont jamais été touchés par l’importation ACF ont continué à fonctionner car ils utilisaient le chemin de stockage plat hérité, que le gestionnaire de sauvegarde lisait. Ce que fait la version actuelle : Le gestionnaire de sauvegarde reconnaît désormais les sous-champs de groupe hiérarchiques et les achemine à travers le même validateur + chemin de stockage que tout autre champ. La solution couvre les types de champs simples tels que texte, zone de texte, WYSIWYG, nombre, sélection, et les autres types de champs “simples” à l’intérieur des groupes, ainsi que les groupes imbriqués à l’intérieur des Repeaters et des mises en page de contenu flexible. Récupération des modifications déjà perdues : Les modifications apportées avant la solution n’ont jamais été persistées — il n’y a aucun enregistrement d’elles à récupérer. Réentrez le contenu et cliquez sur Mettre à jour ; la valeur sera correctement enregistrée.

Les valeurs s’accumulent avec des barres obliques à chaque sauvegarde

Symptômes : Un champ avec des guillemets dans sa valeur (le plus souvent un embed iframe, un bloc WYSIWYG contenant des attributs data-*, ou une zone de texte avec du HTML brut) commence à montrer des barres obliques supplémentaires chaque fois que l’article est enregistré : width="900" devient width=\"900\", puis width=\\\"900\\\", et ainsi de suite — jusqu’à une douzaine ou plus de barres obliques après plusieurs rondes d’édition. La réédition du champ, la création de traductions ou l’utilisation d’outils tiers de “duplication d’article” accélèrent l’accumulation. Pourquoi cela se produit : WordPress ajoute automatiquement une barre oblique avant chaque guillemet dans les données de formulaire. Le gestionnaire de sauvegarde de Field Forge stockait auparavant la valeur reçue sans supprimer ces barres obliques ajoutées, donc chaque ronde de sauvegarde préservait les barres obliques précédentes et en ajoutait une nouvelle couche par-dessus. Les valeurs qui n’ont jamais contenu de guillemets n’étaient pas affectées. Ce que fait la version actuelle : Le gestionnaire de sauvegarde déséchappe les données de formulaire entrantes une fois au début, de sorte que la valeur stockée corresponde à ce que l’utilisateur a réellement tapé. Les sauvegardes futures n’ajoutent plus de barres obliques. Nettoyage des valeurs déjà corrompues :

Ouvrez chaque article affecté dans l’administration. Si la valeur s’affiche avec des barres obliques visibles avant les guillemets, le contenu stocké est corrompu.
Dans l’éditeur de champ, supprimez manuellement les barres obliques et enregistrez une fois — la valeur corrigée persistera à l’avenir.
Pour une réparation en masse sur un site avec de nombreuses lignes corrompues, un script WP-CLI peut itérer stripslashes() sur les valeurs dans wp_fieldforge_values jusqu’à ce que la valeur se stabilise. Limitez le passage aux types de champs de type texte (wysiwyg, textarea, text, url, email) — les identifiants binaires et les valeurs de couleur ne doivent pas être touchés. Contactez le support si vous avez besoin de la requête exacte.

Migration ACF incomplète ou bloquée

Symptômes : La barre de progression de la migration s’arrête à mi-chemin, ou tous les articles n’ont pas leurs données après la migration. Causes et solutions possibles :

Délai d’exécution PHP. Les grands sites peuvent atteindre la limite de temps d’exécution PHP. La migration s’exécute par lots de 50 articles pour éviter cela, mais des serveurs très lents peuvent toujours rencontrer un délai. Augmentez max_execution_time dans vos paramètres PHP (ou php.ini) à au moins 300 secondes, puis redémarrez la migration.
Limite de mémoire. Les articles avec de nombreux champs complexes (répéteurs imbriqués, grandes galeries) peuvent consommer une mémoire significative. Augmentez memory_limit à au moins 256M dans vos paramètres PHP.
ACF a été désactivé avant que la migration ne soit terminée. ACF doit rester actif pendant tout le processus de migration car Field Forge lit les données via les fonctions d’ACF. Réactivez ACF et redémarrez la migration.
Le traitement en arrière-plan a échoué silencieusement. Vérifiez la page d’état de migration de Field Forge pour les messages d’erreur. Si le processus en arrière-plan a été interrompu (redémarrage du serveur, maintenance d’hébergement), cliquez sur “Reprendre la migration” pour continuer là où il s’était arrêté.
Une migration partielle est attendue sur Free. La version gratuite ne migre que les définitions de groupes de champs, pas les valeurs de champ. Si vos articles ont les bons champs mais pas de données, passez à PRO pour migrer les valeurs.
Incompatibilité de bootstrap QA local. Sur les sites QA locaux de Forge qui définissent FORGE_SKIP_LICENSE_REVALIDATION, soit forge_e2e_plan=pro soit un enregistrement de licence locale valide fieldforge_license_data['plan']='pro' déverrouille la migration des valeurs. La même constante locale met également Freemius en mode anonyme pour les demandes d’administration de Field Forge, donc un nouveau site QA ne devrait pas être bloqué par l’écran d’opt-in de Freemius avant d’ouvrir les pages de Field Forge.

JSON local non synchronisé

Symptômes : Vous ou votre développeur avez apporté des modifications aux fichiers JSON, mais les groupes de champs dans la base de données ne se mettent pas à jour. Causes et solutions possibles :

Le JSON local n’est pas activé. Allez dans Field Forge > Paramètres et vérifiez que la synchronisation JSON locale est activée.
Chemin de répertoire incorrect. Field Forge recherche des fichiers JSON dans le dossier fieldforge-json/ à l’intérieur de votre thème actif (ou le chemin personnalisé si configuré). Vérifiez que le dossier existe et contient des fichiers .json. Le chemin est sensible à la casse.
Permissions de fichier. Le serveur web a besoin d’un accès en lecture au répertoire JSON. Sur la plupart des hôtes, des permissions de 755 pour le dossier et 644 pour les fichiers sont correctes.
Notification de synchronisation rejetée. Lorsque Field Forge détecte des fichiers JSON mis à jour, il affiche une notification de synchronisation dans l’administration. Si quelqu’un a rejeté la notification sans cliquer sur Synchroniser, les modifications n’ont pas été appliquées. Allez dans Field Forge > Groupes de champs et recherchez toute notification de synchronisation en attente.
Le thème a été changé. Si le thème actif a changé, Field Forge recherche dans le répertoire du nouveau thème. Assurez-vous que les fichiers JSON existent dans le thème actuellement actif.
Vous importez ACF Local JSON, pas la synchronisation de Field Forge JSON. Les fichiers source ACF appartiennent à acf-json/ et sont gérés par l’outil de migration ACF. Les propres fichiers de synchronisation de Field Forge appartiennent à fieldforge-json/.

La page d’options n’apparaît pas

Symptômes : Vous avez créé une page d’options, mais elle n’apparaît pas dans la barre latérale d’administration de WordPress. Causes et solutions possibles :

PRO n’est pas activé. Les pages d’options nécessitent une licence PRO. Allez dans Field Forge > Licence et vérifiez que votre licence est active.
Incompatibilité de capacité. Si la page d’options a été créée avec une capacité personnalisée, votre compte utilisateur peut ne pas l’avoir. Connectez-vous en tant qu’administrateur pour confirmer que la page existe, puis ajustez le paramètre de capacité si nécessaire.
Conflit de position de menu. Si un autre plugin ou élément de menu occupe le même numéro de position, la page d’options peut être cachée derrière. Essayez de changer la position du menu dans les paramètres de la page d’options.
Cache. Certains plugins de mise en cache ou caches d’objets peuvent mettre en cache le menu d’administration. Videz votre cache et rafraîchissez le tableau de bord de l’administration.

Les modifications de la page d’options disparaissent après l’enregistrement

Symptômes : Vous ouvrez une page d’options (les paramètres du thème “Общие”, une page d’options personnalisée, ou toute page enregistrée via acf_add_options_page / fieldforge_add_options_page), modifiez une valeur ou ajoutez une nouvelle ligne de répétiteur, cliquez sur Enregistrer, voyez l’avis vert “Options enregistrées”, puis lors du rechargement, le formulaire affiche à nouveau l’ANCIENNE valeur. La nouvelle ligne de répétiteur a disparu, le lien de carte modifié est rétabli, la page de Politique de Confidentialité choisie est vide. Pourquoi cela se produit (quatre causes profondes, toutes corrigées ensemble dans v1.0.10) :

L’onglet de langue traduite lit les données de la langue par défaut. La couche de compatibilité n’a pas respecté le commutateur admin LangForge ?lf_lang=, donc l’onglet EN/UZ affichait des valeurs RU. Les modifier écrivait ensuite dans le stockage de la langue par défaut et la langue traduite restait vide.
Les noms de sous-champs composés rejetés par la liste blanche d’enregistrement. Les sous-champs dont le nom contenait un underscore — map_link, privacy_policy, social_name, social_link — étaient silencieusement supprimés du traitement POST car la liste blanche séparait le nom sur _ et exigeait que chaque élément soit un champ enregistré. Leurs valeurs n’atteignaient jamais la base de données.
Le stockage imbriqué have_rows recherchait sous le mauvais préfixe. Un thème appelant have_rows('socials') à l’intérieur de have_rows('common', 'option') cherchait des clés nommées juste socials au lieu de common_socials. Le frontend affichait une section vide même lorsque les données étaient correctement enregistrées.
Le compte de lignes cachées n’était pas mis à jour lorsque vous cliquiez sur Ajouter une ligne ou Supprimer une ligne. Les données de la nouvelle ligne étaient enregistrées, mais l’entrée de compte indiquait toujours l’ancien nombre. Lors du rechargement, le serveur itérait pour ($i = 0; $i < count) et sautait complètement la nouvelle ligne. La ligne était dans la base de données, invisible à la fois pour le formulaire admin et le site public.

Ce que fait la version actuelle : les quatre bugs sont corrigés dans v1.0.10. Les lectures et écritures sur les pages d’options respectent la langue active ; les noms composés passent par la liste blanche via un appariement de préfixe gourmand ; les itérations imbriquées portent le préfixe du champ parent ; Ajouter une ligne / Supprimer une ligne réajuste les index et met à jour l’entrée de compte en direct afin que l’enregistrement/rechargement reflète toujours ce que vous avez soumis. Si vous voyez toujours le symptôme après la mise à niveau :

Rechargez durement la page admin (Cmd+Shift+R / Ctrl+Shift+R) pour récupérer le nouveau admin.js. Le cache buster est automatique lorsque vous téléchargez le nouveau fichier, mais un cache de navigateur obsolète conservera l’ancien comportement.
Vérifiez que l’OPcache PHP de votre hébergement a récupéré les nouveaux fichiers PHP. Sur l’hébergement partagé Hostinger / LiteSpeed, l’OPcache peut conserver les anciens fichiers de classe jusqu’à une heure après le téléchargement. Changez de version PHP dans le panneau ou téléchargez un petit script pour vider le cache.
Si votre site utilise un plugin de traduction autre que LangForge (WPML, Polylang), le filtre fieldforge/options_post_id câblé par LangForge ne se déclenchera pas. La compatibilité des plugins de traduction pour les pages d’options est sur la feuille de route ; pour l’instant, ACF Pro + l’add-on ACFML de WPML est la pile prise en charge sur ces sites.

Les sous-champs Image / Lien de Page / Zone de Texte du Répétiteur affichent des ID numériques bruts dans l’éditeur

Symptômes : Dans un champ Répétiteur sur l’écran d’édition de post, des colonnes comme Image ou Image @2x affichent un numéro brut (800, 2954) dans une entrée de texte au lieu d’un aperçu d’image avec des boutons Sélectionner / Supprimer. Une colonne URL / Lien de Page affiche un ID de post numérique. Une colonne de zone de texte montre une entrée de texte sur une seule ligne qui tronque le contenu long. Cause (corrigée le 2026-04-24) : Le rendu du Répétiteur avait codé en dur chaque sous-champ pour se rendre en tant que , ignorant le type réel du sous-champ. Les champs de premier niveau des mêmes types se rendaient correctement via le rendu d’entrée conscient du type — seul le chemin du répétiteur a sauté le dispatch. Correction : Mettez à jour Field Forge vers la dernière version. Les sous-champs du Répétiteur se dispatchent maintenant vers le même rendu conscient du type que les champs de premier niveau : les sous-champs d’image reviennent avec des vignettes d’aperçu + des boutons Sélectionner / Supprimer, les sous-champs page_link et post_object se rendent sous forme de listes déroulantes de pages+posts publiés, les zones de texte se rendent sous forme de zones de texte multi-lignes. Le comportement d’enregistrement et le schéma de nom d’entrée HTML restent inchangés, donc les valeurs précédemment éditées demeurent.

Répétiteur imbriqué à l’intérieur d’un Répétiteur affiche un nombre dans une entrée de texte

Symptômes : Un Répétiteur a un sous-champ qui est lui-même un Répétiteur (par exemple, un bloc de Prix annuel où chaque année contient une liste d’éléments de prix individuels). Sur l’écran d’édition de post, les lignes extérieures se rendent correctement, mais la colonne imbriquée affiche un simple nombre à un ou deux chiffres dans une entrée de texte — le nombre correspond au compte des lignes intérieures pour cette ligne extérieure. Cliquer sur le “nombre” ne fait rien, et il n’y a aucun moyen d’éditer les éléments intérieurs depuis l’éditeur. Le frontend public se rend correctement car le chemin de lecture n’a jamais été rompu. Cause (corrigée le 2026-04-24) : Le dispatcher par ligne introduit le 2026-04-24 gérait les types de sous-champs simples (image, zone de texte, page_link, post_object, etc.) mais acheminait toujours les types composés imbriqués — Répétiteur, Groupe, Contenu Flexible — via l’entrée de texte de secours. La chaîne de secours a transformé la valeur du compte de lignes du répétiteur imbriqué, ce qui est comment le chiffre est apparu à la place de l’interface utilisateur réelle. Correction : Mettez à jour Field Forge vers la dernière version. Le rendu du répétiteur détecte maintenant quand le type d’un sous-champ est l’un de repeater / group / flexible_content et délègue au rendu composé partagé avec l’ID d’enregistrement imbriqué que le chargeur de valeur stocke sur chaque ligne. Les répétiteurs imbriqués se rendent maintenant avec leurs propres lignes avec des poignées de glissement, des boutons de poubelle, et des entrées de sous-champ entièrement fonctionnelles (images, zones de texte, etc.), et les groupes imbriqués rendent leurs grilles de sous-champs. Le comportement d’enregistrement et le schéma de nom d’entrée HTML restent inchangés — les données existantes deviennent éditables lors du prochain chargement de page sans migration de données requise.

Le bouton “Ajouter une ligne” du Répétiteur se rend sans étiquette (Pillule vide en bas du Répétiteur)

Symptômes : En bas d’un Répétiteur (et des Répétiteurs imbriqués et des blocs de Contenu Flexible), il y a une ovale vide à contour rose où le bouton “Ajouter une ligne” / “Ajouter une mise en page” devrait être. Cliquer dessus ajoute toujours une ligne, mais il n’y a pas d’étiquette visible pour guider l’éditeur. Cause (corrigée le 2026-04-24) : Pour les répétiteurs migrés depuis ACF, button_label est stocké comme une chaîne vide plutôt que null. Le rendu utilisait $field['button_label'] ?? __('Add Row') pour revenir à l’étiquette par défaut, mais ?? ne se déclenche que sur null — une chaîne vide passe, donc le bouton se rendait sans texte. Correction : Mettez à jour Field Forge vers la dernière version. La chaîne de secours utilise maintenant !empty(...) donc à la fois null et les chaînes vides se résolvent à l’étiquette par défaut “Ajouter une ligne” / “Ajouter une mise en page”. Définir un button_label personnalisé dans l’éditeur de groupe de champs fonctionne toujours exactement comme avant.

La largeur du sous-champ à l’intérieur d’un Répétiteur est ignorée (toutes les colonnes se rendent avec des largeurs égales)

Symptômes : Dans l’éditeur de groupe de champs, un Répétiteur a des sous-champs avec des valeurs explicites de Width % (par exemple, Année 20% et Prix 80%), mais sur l’écran d’édition de post, chaque colonne de sous-champ prend une part égale de la ligne — deux sous-champs se retrouvent à 50%/50%, quatre à 25%/25%/25%/25%, etc. Le paramètre Width % semble s’enregistrer mais n’a aucun effet visible. Cause (corrigée le 2026-04-24) : La mise en page de ligne du répétiteur utilisait un conteneur flex avec flex: 1 sur chaque cellule, remplaçant tout wrapper.width que le sous-champ portait. Les champs de premier niveau émettaient un style en ligne à partir de leur largeur d’enveloppe, mais le chemin de cellule du répétiteur n’avait pas de telle branche. Correction : Mettez à jour Field Forge vers la dernière version. Chaque cellule de sous-champ du répétiteur émet maintenant un attribut data-width="N" et un style en ligne flex: 0 0 calc(N% - 8px); max-width: calc(N% - 8px) dérivé de la wrapper.width du sous-champ, à l’intérieur d’une ligne flex avec gap: 8px et flex-wrap: wrap. Les largeurs sont respectées pour les répétiteurs extérieurs et les répétiteurs/groupes/flexibles imbriqués. Les cellules sans largeur configurée tombent toujours en retour à flex: 1 et partagent la ligne de manière égale.

Le badge de largeur % dans l’éditeur ne se met pas à jour lorsque vous tapez

Symptômes : Dans l’éditeur de groupe de champs, chaque sous-champ a un petit badge rose à côté de son étiquette de type (par exemple, “Texte 20%”) qui reflète son wrapper.width. Taper une nouvelle valeur dans l’entrée de largeur % change l’entrée mais laisse le badge inchangé jusqu’à ce que la page soit enregistrée et rechargée — donnant l’impression que le changement n’est pas enregistré. Cause (corrigée le 2026-04-24) : Le badge était rendu une fois à partir de la valeur côté serveur lors du chargement initial. Le gestionnaire d’entrée en direct mettait à jour l’état du champ JS mais ne touchait pas l’élément du badge, donc les deux visuels s’éloignaient jusqu’au prochain rechargement complet. Correction : Mettez à jour Field Forge vers la dernière version. Le gestionnaire d’entrée wrapper.width reflète maintenant la valeur actuelle dans le badge rose en temps réel — ajoutant le badge lorsque la largeur est d’abord définie, mettant à jour son texte au fur et à mesure que vous tapez, et le supprimant lorsque le champ est vidé. Aucun changement fonctionnel, uniquement une amélioration de la cohérence visuelle.

La page traduite (WPML) rend le texte de la langue source pour les champs de groupe

Symptômes : Après avoir traduit un post avec WPML, le frontend public de la langue traduite montre le contenu de la langue source pour les champs stockés à l’intérieur d’un Groupe — même si la metabox Field Forge dans l’admin montre clairement la bonne traduction. Manifestation typique : un bloc de détails de projet rend des étiquettes en anglais sous une URL russe (ou vice versa). Cause (corrigée le 2026-04-24) : WPML duplique les postmeta du post source sur la traduction au moment de la traduction et ne les maintient pas synchronisés avec les modifications ultérieures. Vos modifications aux sous-champs de Groupe du post traduit sont enregistrées dans la propre table de Field Forge (wp_fieldforge_values) contre l’ID du post traduit, mais la couche de compatibilité ACF héritée lisait les valeurs de Groupe uniquement à partir de get_post_meta(), qui pour le post traduit renvoyait toujours la copie de langue source intacte. Correction : Mettez à jour Field Forge vers la dernière version. La couche de compatibilité préfère maintenant les valeurs de wp_fieldforge_values lorsqu’un enregistrement existe pour le post actuel, retombe sur get_post_meta() uniquement lorsqu’aucun enregistrement n’est trouvé, et remplit défensivement les sous-champs manquants à partir du postmeta ACF afin que les groupes partiellement migrés se dégradent gracieusement. Aucune migration de données n’est requise — les traductions existantes deviennent correctes lors du prochain chargement de page.

Le contenu Wysiwyg / Image / Texte disparaît après une boucle imbriquée `have_rows`

Symptômes : Un modèle de thème itère un champ répétiteur ou flexible_content à l’intérieur d’un autre (par exemple un video ou un bloc image imbriqué à l’intérieur d’un groupe topside), et immédiatement après la boucle intérieure appelle the_sub_field('textblock') ou the_sub_field('img') sur la ligne extérieure — la valeur revient vide, donc le balisage environnant semble cassé. Les images se rendent avec src="" et montrent uniquement le texte alt comme solution de secours ; les blocs de texte disparaissent complètement. Cause (corrigée le 2026-04-24) : Lorsqu’une itération de have_rows() était terminée, la couche de compatibilité effaçait inconditionnellement le pointeur de ligne actuel, même si l’itération était imbriquée à l’intérieur d’une boucle extérieure encore active. Le comportement réel d’ACF est que la ligne actuelle de la boucle extérieure persiste jusqu’à la fin de l’itération extérieure. Correction : Mettez à jour Field Forge vers la dernière version. À la fin de l’itération, la couche de compatibilité restaure maintenant la ligne actuelle à la boucle encore active la plus récente sur la pile et ne l’efface que lorsque aucune boucle n’est active. Les modèles qui mélangent les appels imbriqués de have_rows — un modèle ACF courant — fonctionnent maintenant comme prévu.

Bouton “Ajouter une ligne” du Repeater ne fonctionne pas

Symptômes : Cliquer sur “Ajouter une ligne” dans un champ repeater ne fait rien, ou le bouton est grisé. Causes possibles et solutions :

Nombre maximum de lignes atteint. Si le repeater a un paramètre de nombre maximum de lignes et que vous avez atteint cette limite, le bouton Ajouter une ligne est désactivé. Vérifiez la configuration du repeater pour une valeur de lignes maximum.
Erreur JavaScript. Ouvrez la console de développement de votre navigateur (F12 ou Cmd+Option+I) et vérifiez les erreurs JavaScript. Un conflit avec un autre plugin ou un script de thème peut empêcher le fonctionnement du repeater. Les coupables courants sont les plugins de construction de pages ou les plugins d’optimisation admin qui concatènent agressivement les scripts.
Licence PRO inactive. Le repeater est un type de champ PRO. Si votre licence a expiré ou a été désactivée, la fonctionnalité du repeater peut être limitée. Vérifiez Field Forge > Licence.
Compatibilité du navigateur. Essayez un autre navigateur ou videz le cache de votre navigateur. Les versions de navigateur obsolètes ont parfois des problèmes avec les éléments de formulaire dynamiques.

Dispositions de contenu flexible manquantes

Symptômes : Lorsque vous cliquez sur “Ajouter une disposition” dans un champ de contenu flexible, le menu déroulant est vide ou certaines dispositions sont manquantes. Causes possibles et solutions :

Les dispositions n’ont pas été définies. Ouvrez l’éditeur de groupe de champs et vérifiez le champ de contenu flexible. Chaque disposition doit être explicitement ajoutée avec un nom et des sous-champs. Si une disposition a été accidentellement supprimée, utilisez l’historique des révisions pour la restaurer.
Nombre maximum de dispositions atteint. Si un maximum a été défini pour un type de disposition spécifique, elle disparaîtra du menu déroulant une fois cette limite atteinte. Supprimez une instance existante de cette disposition pour libérer l’emplacement.
Logique conditionnelle cachant des dispositions. Si une logique conditionnelle est configurée sur les dispositions, certaines peuvent être cachées en fonction des valeurs d’autres champs. Vérifiez les paramètres de logique conditionnelle.
Problème de licence PRO. Le contenu flexible nécessite PRO. Vérifiez l’état de votre licence.

Problèmes de performance avec de nombreux groupes de champs

Symptômes : La zone admin semble lente lors de l’édition des articles, ou la liste des groupes de champs met beaucoup de temps à se charger. Causes possibles et solutions :

Trop de champs sur un seul article. Si un seul article correspond à de nombreux groupes de champs (ce qui entraîne 50+ champs), l’éditeur peut devenir lent. Consolidez les groupes de champs lorsque cela est possible ou utilisez des champs d’onglet pour organiser de grands groupes en sections. Les onglets chargent les champs de manière paresseuse, améliorant la performance perçue.
Logique conditionnelle complexe. Une logique conditionnelle étendue avec de nombreuses règles interconnectées nécessite plus de traitement JavaScript. Simplifiez les conditions lorsque cela est possible.
Limitations d’hébergement. L’hébergement partagé avec un CPU et une mémoire limités peut avoir des difficultés avec des pages admin complexes. Envisagez de passer à un hébergement WordPress géré si la performance admin est constamment médiocre.
Mise en cache des objets. Installez un plugin de mise en cache des objets (comme Redis ou Memcached) pour réduire les requêtes de base de données. Field Forge bénéficie de la mise en cache des objets car les définitions de groupes de champs sont mises en cache après le premier chargement.

Conflit avec ACF (les deux actifs)

Symptômes : Comportement étrange, métaboxes en double, champs affichant des valeurs du mauvais plugin, ou erreurs PHP mentionnant la redéclaration de fonction. Causes possibles et solutions :

Désactivez un plugin. Exécuter à la fois ACF et Field Forge simultanément est uniquement prévu pendant la migration. Après la migration, désactivez ACF. Field Forge fournit toutes les mêmes fonctions, donc votre code de thème continue de fonctionner.
Conflit de fonction. Si les deux plugins essaient d’enregistrer get_field(), PHP génère une erreur fatale concernant les déclarations de fonction en double. Les versions actuelles de Field Forge se réfèrent à ACF chaque fois qu’ACF est actif ou en cours d’activation via l’admin/plugin WordPress, donc ACF Pro peut être activé pour la migration sans rencontrer une erreur fatale de redéclaration get_field(). Si vous voyez toujours cette erreur, mettez à jour Field Forge en premier, rechargez les plugins et activez ACF à nouveau.
Fallback de la page d’options pendant la migration. Si ACF est actif et renvoie une valeur d’option vide tandis que Field Forge a la valeur d’option spécifique à la langue, Field Forge fournit cette valeur via le filtre de chargement de valeur d’ACF. Ce pont étroit maintient la cohérence des sondages de page d’options conscients de LangForge pendant la migration ; cela ne rend pas l’opération duale ACF/Field Forge à long terme la configuration recommandée.
Métaboxes doubles. Si vous voyez deux ensembles des mêmes champs sur un article, l’un provenant d’ACF et l’autre de Field Forge, cela signifie que les deux plugins ont des groupes de champs et des règles de localisation correspondants. Désactivez ACF pour éliminer les doublons.

Valeurs de champ perdues après changement de thème

Symptômes : Après être passé à un nouveau thème, les données de champ personnalisées semblent manquantes sur le frontend. Causes possibles et solutions :

Les modèles de thème n’ont pas été mis à jour. Les données de champ sont toujours dans la base de données — elles ne disparaissent pas lorsque vous changez de thème. Le problème est que le nouveau thème ne contient pas le code de modèle (get_field(), the_field(), etc.) pour l’afficher. Demandez à votre développeur d’ajouter le code de sortie des champs aux modèles du nouveau thème.
Le chemin JSON local a changé. Si vous utilisiez la synchronisation JSON locale, les fichiers JSON étaient dans le dossier de l’ancien thème. Copiez le répertoire fieldforge-json/ de l’ancien thème vers le nouveau, ou reconfigurez le chemin JSON local dans Field Forge > Paramètres.
Les groupes de champs sont intacts. Allez à Field Forge > Groupes de champs pour confirmer que tous vos groupes de champs existent toujours. Ils sont stockés dans la base de données, pas dans le thème, donc ils survivent à un changement de thème.

Erreurs de génération TypeScript

Symptômes : La fonctionnalité de génération TypeScript produit des types incorrects, génère des erreurs ou produit des fichiers vides. Causes possibles et solutions :

Licence PRO requise. La génération TypeScript est une fonctionnalité PRO. Vérifiez que votre licence est active.
Aucun groupe de champs défini. Les interfaces TypeScript sont générées à partir de vos définitions de groupes de champs. Si vous n’avez pas de groupes de champs, la sortie sera vide.
Types de champs non pris en charge dans les plugins personnalisés. Si vous avez enregistré des types de champs personnalisés via un plugin, le générateur TypeScript peut ne pas savoir comment les mapper. Vérifiez la sortie générée pour les types any et ajoutez des mappages de types personnalisés en utilisant le filtre fieldforge/typescript/type_map.
Permissions d’écriture de fichier. Si le fichier de sortie ne peut pas être écrit, vérifiez que le répertoire cible a des permissions d’écriture pour le serveur web.

Échecs d’importation/exportation

Symptômes : L’importation d’un fichier JSON échoue, ou le fichier exporté est vide ou corrompu. Causes possibles et solutions :

Format JSON invalide. Si vous avez modifié manuellement un fichier d’exportation JSON, une erreur de syntaxe (virgule manquante, crochet supplémentaire) entraînera l’échec de l’importation. Utilisez un validateur JSON (comme jsonlint.com) pour vérifier le fichier avant l’importation.
Fichier trop volumineux. Des exportations très volumineuses (des centaines de groupes de champs) peuvent dépasser les limites de PHP upload_max_filesize ou post_max_size. Augmentez ces valeurs dans votre configuration PHP, ou divisez l’exportation en fichiers plus petits.
Définitions de champs inconnues ou malformées. Field Forge rejette les importations contenant un type de champ inconnu, des sous-champs malformés, des dispositions de contenu flexible malformées, ou des règles de localisation invalides. Mettez à jour les deux sites vers la dernière version de Field Forge et exportez à nouveau le JSON depuis le site source au lieu de modifier manuellement ces sections.
Incompatibilité de version. L’importation d’un fichier exporté d’une version plus récente de Field Forge dans une version plus ancienne peut échouer si la version plus récente a ajouté des types de champs ou des paramètres que la version plus ancienne ne reconnaît pas. Mettez à jour Field Forge vers la dernière version avant d’importer.
Problèmes de permission. Le serveur web a besoin d’un accès en écriture au répertoire uploads pour le traitement des fichiers temporaires lors de l’importation. Vérifiez les permissions des dossiers.
Clés de champ en double. Si l’importation contient des clés de champ qui existent déjà dans votre base de données, Field Forge affiche un avis de conflit. Choisissez de remplacer les groupes existants ou de sauter les doublons.