Identifier ce que le bloc devrait afficher
Vous ouvrez une fiche WordPress et la salle de retrait est absente, ou bien le bloc affiche la salle d’une autre fiche. Pourtant, le champ semble rempli dans l’éditeur. Avant de retaper la valeur, regardez quelle donnée le bloc demande à Pods. Une erreur de cible peut donner une valeur parfaitement lisible et fausse. Une erreur de champ peut produire le même blanc qu’une donnée réellement vide. Le rendu, à lui seul, ne départage pas ces cas.
Ce parcours concerne le bloc Pods Field Value avec un champ de texte simple sur la page individuelle d’une fiche. Il commence quand le champ existe. Si vous ne voyez aucun champ dans l’éditeur, commencez par vérifier la configuration du type de contenu et des champs. Si la fiche est absente d’une page de résultats, le problème se trouve plus tôt dans la sélection des fiches. Le test ici suppose que les deux pages s’ouvrent et que vous pouvez identifier le bloc qui affiche la valeur.
Posez la règle avant d’essayer un changement. Dans un modèle qui sert à toutes les fiches, la salle affichée doit suivre la fiche ouverte. Une page de renseignements peut au contraire toujours citer une salle de référence : dans ce cas, une cible fixe est utile. Demandez quelle règle s’applique à l’emplacement où vous avez vu le défaut. Retirer une cible fixe sur une page qui devait garder la même valeur créerait un autre problème, même si la salle affichée au moment de l’essai paraît correcte.
Pour l’exercice, le titre de la page et le texte de la salle sont deux repères indépendants. Sur « Fiche fictive A », attendez « Salle Azur ». Sur « Fiche fictive B », attendez « Salle Ambre ». Voir le bon titre et la mauvaise salle sur la même page indique que la page ouverte est la bonne, mais que la source de la valeur doit être vérifiée. Conservez cette distinction dans vos captures ou vos notes.
Préparer deux fiches avec des valeurs reconnaissables
Dans une copie de travail, préparez un type de contenu Pods de test ou choisissez deux fiches fictives du même type. Le champ de l’exercice s’appelle « Salle de retrait » à l’écran. Son nom technique est salle_retrait. Saisissez « Salle Azur » dans A et « Salle Ambre » dans B. Enregistrez les deux fiches, rouvrez-les et confirmez que les deux valeurs sont bien sauvegardées. Deux valeurs différentes vous permettent de suivre la source. Avec « Salle 1 » des deux côtés, le bloc peut lire la mauvaise fiche sans que le test le révèle.
Repérez une URL pour chacune des fiches et notez son titre, son type et son identifiant dans la copie. Un nom visible comme « Fiche A » n’est ni son slug ni son identifiant. Même si un titre ressemble au slug, relevez la valeur réelle. Un identifiant de la copie peut différer de celui d’un autre environnement. Gardez les identifiants dans les notes de recette plutôt que de les présenter comme une configuration à recopier ailleurs.
Ajoutez le même bloc à A et B, ou relevez celui que le modèle utilise déjà. Faites une copie des réglages avant d’y toucher : nom du Pod, slug ou identifiant, nom du champ et emplacement du bloc. Si le bloc se trouve dans un modèle partagé ou un contenu synchronisé, dupliquez cet élément dans l’environnement de travail avant l’expérience. Un seul changement sur un élément partagé peut toucher toutes les fiches. Le témoin B est utile seulement si vous savez quels réglages il partage avec A et quels réglages lui sont propres.
Ouvrez ensuite chaque fiche comme un visiteur, à une adresse qui correspond bien à sa page individuelle. Notez la valeur juste sous le bloc testé, plutôt qu’un mot trouvé n’importe où dans la page. La salle peut aussi apparaître dans un titre, une carte ou un paragraphe saisi à la main. Dans l’exercice, un titre de fiche confirme la page demandée et une zone de rendu distincte confirme la sortie du bloc.
Relever le nom du champ et la fiche que Pods doit lire
Dans les réglages de Pods Field Value, repérez le nom du Pod, la case de slug ou d’identifiant et le nom du champ. Les intitulés peuvent être traduits. « Salle de retrait » aide les personnes qui saisissent les fiches, mais le bloc attend le nom technique du champ. Comparez ce nom au réglage réel de Pods. Dans notre témoin, salle_retait est une faute facile à manquer. Le bloc devient vide alors que « Salle Azur » reste enregistrée dans le bon champ.
Regardez ensuite la cible. Pour un essai fixe, renseignez le Pod et un slug ou identifiant de fiche dont vous avez vérifié la valeur. Si le bloc de A utilise l’identifiant de B, « Salle Ambre » peut apparaître sur la page A. Le champ lui-même fonctionne : la preuve est que le texte correspond exactement à l’autre fiche. Si vous avez dupliqué une fiche ou déplacé un bloc depuis une page de référence, cherchez en priorité un identifiant resté dans la copie.
Pour lire le champ de la fiche courante dans l’exercice, laissez le Pod sur le choix qui utilise le contexte courant et ne renseignez ni slug ni identifiant fixe. Gardez le nom technique du champ. L’exemple ci-dessous est la représentation enregistrée du bloc dynamique dans la recette. Vous pouvez comparer ce repère au code d’une copie. Pour effectuer la correction, préférez les réglages du bloc à une réécriture manuelle de ses commentaires.
Il faut distinguer la fiche qui porte le bloc de la fiche que le bloc est censé lire. Le test porte sur une fiche individuelle. Un bloc dans une boucle, un modèle de constructeur ou un aperçu de l’éditeur peut recevoir un autre contexte. Si le défaut n’existe que dans un de ces emplacements, reproduisez l’emplacement exact sur votre copie et testez deux lignes ou deux pages. Le résultat d’une fiche individuelle ne prouve pas le comportement de ces configurations.
<!-- wp:pods/pods-block-field {"field":"salle_retrait"} /-->Distinguer trois causes en comparant avec la référence
Commencez avec le champ correct et la fiche courante. A affiche « Salle Azur », B affiche « Salle Ambre ». Relevez ce résultat avant de provoquer un défaut. Sur la copie de A seulement, gardez le champ correct et donnez au bloc la cible fixe B. Sur A, la sortie devient « Salle Ambre » alors que « Salle Azur » reste enregistrée dans A. Si B continue à afficher « Salle Ambre », vous avez un exemple de mauvais ciblage sans perte de données. Revenez au réglage de référence pour l’essai suivant.
Sur A, remplacez le nom technique par la faute volontaire salle_retait. Laissez le reste identique à la référence. Dans la recette, la zone du bloc reste vide alors que la donnée A est toujours présente. Vérifiez la différence dans les réglages et remettez le nom exact. Si vous voyez un message d’erreur dans votre interface, gardez ce message dans vos notes et observez aussi la page côté visiteur. Le test cherche la relation entre la demande du bloc et le résultat public.
Pour le troisième essai, gardez le bon champ et la bonne cible. Videz seulement la valeur de A dans la copie, en conservant « Salle Azur » dans vos notes. A redevient vide et B garde « Salle Ambre ». Rouvrez A et constatez que le champ existe mais ne contient plus de valeur. Vous avez les deux contrôles qui manquaient pour expliquer le blanc : le champ demandé est bien celui qui est configuré, et la fiche effectivement lue n’a plus de valeur. Remettez immédiatement « Salle Azur » avant de poursuivre.
Ces essais servent à comparer des résultats, pas à créer trois correctifs. Sur votre site de travail, choisissez la branche qui correspond à ce que vous constatez. Si le bon champ contient une valeur et que le bloc pointe déjà vers la bonne fiche, arrêtez de modifier les données. Essayez alors un bloc identique sur une fiche isolée. S’il fonctionne, comparez l’emplacement et le modèle. S’il échoue aussi, cherchez si l’affichage dépend du rôle, du statut de la fiche ou d’un réglage de Pods avant de modifier un autre champ.
Choisir le réglage qui correspond à la page
Si la salle doit suivre la fiche, retirez la cible fixe et utilisez le contexte courant, puis vérifiez A et B. C’est le passage de A à B qui prouve que le rendu suit la fiche. Tester A seulement après avoir remis l’identifiant de A peut masquer le défaut jusqu’à la prochaine duplication. Pour un modèle partagé, enregistrez la modification dans sa copie, puis contrôlez au moins deux pages qui l’utilisent et une qui ne l’utilise pas. Celle qui ne l’utilise pas sert à vérifier que l’intervention est restée au bon endroit.
Si la salle doit provenir d’une fiche déterminée, gardez une cible fixe et corrigez-la. Vérifiez le Pod, puis l’identifiant ou le slug de la fiche que cette page doit citer. Dans la recette, viser explicitement A sur la page A rend à nouveau « Salle Azur ». Pour prouver qu’une cible fixe répond vraiment à votre besoin, choisissez une seconde page sur laquelle le même bloc est censé lire cette source. Son propre champ peut être différent. Il faut pouvoir expliquer pourquoi la sortie reste identique. Documentez aussi ce qui devra être revérifié si la fiche de référence est déplacée ou remplacée.
Si le réglage est bon mais que la donnée manque, faites compléter la fiche à partir d’une information vérifiée. Une salle vide peut aussi signifier que le lieu n’est pas encore déterminé. Convenez alors du comportement prévu pour une valeur inconnue. Une valeur inventée ou reprise de B supprimerait le blanc tout en introduisant une erreur. Si le nom du champ est en cause, changez le réglage du bloc. Renommer le champ Pods pour l’aligner sur la faute de frappe risquerait de casser ses autres usages.
Faites un seul changement justifié puis ouvrez les deux fiches sans connexion. Lorsque l’éditeur et la page visiteur diffèrent, vérifiez que vous comparez la même version et le même emplacement avant de suspecter les droits. Pods peut limiter l’affichage de certaines données. Confirmez que la valeur est destinée aux visiteurs et demandez la vérification du réglage pertinent. Élargir l’accès à tout le type ou à tous les champs ne permet pas de prouver que le bloc lisait la mauvaise fiche.
Vérifier la sortie et rétablir la configuration initiale
Dans l’expérience fournie, WordPress et Pods chargent un vrai type de contenu et un vrai bloc dynamique sur une instance locale. Le test lit la valeur du champ sur chaque fiche par l’API Pods, relève le réglage enregistré du bloc, puis demande le document en HTTP comme un visiteur. Le résultat est extrait de la zone du bloc et comparé au titre de la fiche. La donnée et le rendu peuvent alors être comparés sans que l’un serve de preuve pour l’autre. La fiche B reste stable dans les six états.
Le retour arrière dépend de ce que vous avez changé. Pour un essai de cible ou de nom de champ, remettez les réglages de référence du bloc. Dans la recette, le bloc fixe sur A est remplacé par le balisage d’origine qui utilise la fiche courante. La sortie de A reste « Salle Azur » et celle de B « Salle Ambre ». Comparez le contenu enregistré ainsi que le rendu. Si la donnée a été modifiée pendant l’essai, remettez-la séparément et rouvrez la fiche. Restaurer le corps de la page ne prouve pas que la valeur d’un champ personnalisé a été restaurée. Il faut relire les deux.
Lorsque le bloc vit dans un modèle partagé, rétablissez le réglage là où vous l’avez modifié. Si d’autres personnes ont changé le modèle entre-temps, évitez de restaurer une copie entière sans comparer les écarts. Revenez au seul réglage de cible ou de champ quand cela suffit. Après le retour arrière, refaites le test sur A et B. Si A reste fausse et que sa donnée est correcte, conservez l’ancien et le nouveau réglage pour la personne qui reprend. Cette trace permet de repartir d’une différence observable au lieu de rejouer les mêmes changements.
Gardez les preuves au même endroit : la fiche et son URL de test, les deux valeurs attendues, le réglage avant et après, et la valeur lue par un visiteur. Le test fourni ne couvre ni les relations entre fiches ni les boucles imbriquées. Si votre défaut se trouve dans une boucle, notez ce qui change entre ses lignes avant de tenter un autre correctif. Ce dossier est prêt à relire quand quelqu’un peut expliquer pourquoi la valeur est vide ou d’où vient la valeur étrangère, puis reproduire le réglage et son retour arrière.
Si le témoin fonctionne mais pas la fiche d’origine
Comparez d’abord la demande telle qu’elle arrive au bloc. Relevez l’adresse exacte, le titre de la fiche, son type et le réglage enregistré. Si une page de test lit « Salle Azur » et qu’une autre reste vide, le fait de retrouver les mêmes options à l’écran ne prouve pas qu’elles proviennent du même bloc. Dans l’éditeur, cherchez l’emplacement qui produit la zone observée. Sur la page visiteur, inspectez cette zone. Si la bonne valeur est présente dans le HTML mais invisible à l’écran, le bloc a fourni une sortie. Poursuivez du côté de l’affichage avant de corriger les données Pods.
Si la valeur n’est pas dans le HTML, comparez les deux pages dans les mêmes conditions : mêmes droits de visiteur, même type de fiche, même modèle ou même emplacement du bloc. Si la copie isolée fonctionne et que le modèle partagé échoue, remettez le bloc à sa place d’origine sur la copie pour vérifier si le défaut revient. Pour une demande d’aide, transmettez les noms techniques, les réglages du bloc, les valeurs fictives attendues et les deux résultats observés. Cela suffit pour décrire le défaut sans transmettre une fiche réelle ni les identifiants d’un compte.
