Boucle sur les réponses de formidable

Bonjour,
Je gère le site internet d’un festival qui fait appel à de nombreux bénévoles. À partir d’une liste des postes et des créneaux horaires disponibles pour chacun des postes, les bénévoles s’inscrivent via un formulaire formidable présent sur une page générique.
Cette page est appelée par une url qui envoie au formulaire le nom du poste (postname) et le créneau horaire (time) choisis :

ex : ruedesarts.net/?page=inscription&postname=Buvette église Vendredi&time=16h-18h

postname et time sont récupérés/traités par le formulaire sous forme de champ cachés, le bénévole se contentant de renseigner son nom, son numéro de portable etc…

Ça fonctionne bien. Là où je coince c’est que je souhaiterais faire apparaitre sous le formulaire d’inscription la liste des personnes déjà inscrites à ce poste et à cet horaire

J’ai essayé sans succès la boucle :

<BOUCLE_inscrits(FORMULAIRES_REPONSES spip_formulaires_reponses_champs){id_formulaire=9}{hidden_1=#ENV{postname}}{hidden_2 = #ENV{time}}>

Quelqu’un(e) d’entre vous saurait comment faire ?
Merci+++ d’avance

La documentation Boucler sur les réponses de Formidable - SPIP-Contrib
indique que les critères sont de la forme {nom=checkbox_1} {valeur!=''}
Donc dans ton cas ce serait {nom=hidden_1} {valeur=#ENV{postname}}

Sauf que tu as 2 critères, donc dans cette boucle il ne faut retenir que les horaires voulus. Ça pourrait être une nouvelle boucle imbriquée, mais aussi plus simplement avec juste un test dans la boucle :

[(#VOIR_REPONSE{hidden_2}|=={#ENV{time}}|oui) 
    afficher ce que tu veux ici
]

À affiner probablement.

Merci de ta réponse.

Tel quel, cela ne fonctionne pas. J’ai tenté d’adapter le code en essayant

[(#VOIR_REPONSE{hidden_2,valeur_uniquement}|=={#ENV{time}}|oui) 
    afficher ce que tu veux ici
]

Mais ça n’est pas mieux.
Tout se passe comme si le test d’égalité entre hidden_2 et env{time} ne fonctionnait pas bien que, a priori, hidden_2, valeur_uniquement et #ENV(time) contiennent la même chose

Il y a un loup quelque part et il doit bien y avoir une astuce pour que le loup disparaisse…

Il faudrait voir les 2 valeurs non encodées pour pouvoir les comparer, et donc afficher les valeurs brutes dans un <pre> (ou un <xmp> désuet)

<pre>
hidden_2=[(#VOIR_REPONSE{hidden_2,valeur_uniquement})]
time=[(#ENV{time})]
</pre>

J’ai mis valeur_uniquement comme toi mais je ne sais pas si c’est ce qu’il faut.

Et il pourrait y avoir des * en plus pour ne pas appeler les traitements.

Si ça peut aider à identifier le loup…

Il n’y a pas de <pre> dans ton code donc on ne peut pas savoir ce qui est produit, on voit seulement ce qui s’affiche, mais SPIP ne teste pas l’affichage, SPIP teste ce qui est produit et c’est ce test qu’on veut débuguer, donc ça aide pas là comme ça.

Donc STP ajoute le pre comme indiqué précédemment.

Et aussi met quelque chose autour, par exemple des " comme ça on verra s’il y a pas un problème d’espace en trop dans une des valeurs.

Donc <pre>"#ENV{time}"</pre> par exemple.

Oui, je n’avais pas mis car

<pre>
time=[(#ENV{time})]
</pre>
...

donne comme réponse time=12h-14h

mais

hidden_2=[(#VOIR_REPONSE{hidden_2,valeur_uniquement})]

donne....
Erreur d’exécution squelettes/content/inscription.html | File […]/plugins/auto/saisies/v5.11.1/inc/saisies_lister.php Line 488 : Cannot unset string offsets

Ce n’est pas l’ajout du pre qui cause cette erreur + pour y voir qqchose il faut des pre et " autour des 2 affichages

Ah, j’ai mal écrit, désolé :
<pre> time=[(#ENV{time})] </pre>
donne comme réponse time=12h-14h

Et <pre> hidden_2=[(#VOIR_REPONSE{hidden_2,valeur_uniquement})] </pre>
provoque « Erreur d’exécution squelettes/content/inscription.html »
et la fenêtre debug affiche :

Erreur d’exécution squelettes/content/inscription.html | File […]/plugins/auto/saisies/v5.11.1/inc/saisies_lister.php Line 488 : Cannot unset string offsets
(voir copie d’écran)

[Résolu ?]
Pour une raison qui m’échappe (mais je veux bien avoir l’explication !), dans la BOUCLE_inscrits #VOIR_REPONSE{hidden_2,valeur_uniquement}
ne renvoie pas xxh-yyh (qui est pourtant la valeur présente dans la base de donnée mais <p>xxh-yyh</p>

Du coup, la présence des balises fait que le test de comparaison ne peut jamais donner « vrai ».

J’ai tenté d’écrire #VOIR_REPONSE*{hidden_2,valeur_uniquement} mais sans effet.
Du coup j’ai fait appel au filtre |supprimer_tags

<BOUCLE_inscrits(FORMULAIRES_REPONSES spip_formulaires_reponses_champs)
{id_formulaire=9}{nom=hidden_1}
{valeur=#ENV{postname}}>
[(#VOIR_REPONSE{hidden_2,valeur_uniquement}|supprimer_tags|=={#ENV{time}}|oui)#VOIR_REPONSE{input_1,valeur_uniquement}]</BOUCLE_inscrits>
</B_inscrits>

et cela semble fonctionner…


Question subsidiaire : dans la partie optionnelle de la boucle en question, j’ai écrit le code suivant dans l’idée d’introduire/expliquer le résultat de la boucle :

<h4>Sont déjà inscrit(e)s au poste #ENV{postname} pour le créneau #ENV{time}</h4>

Sur la page web produite, la valeur de #ENV{postname} est « collée » au mot suivant (en gras ci-dessous)
Exemple : Sont déjà inscrit(e)s au poste Brouzoufs Vendredipour le créneau 12h-14h

J’ai essayé sans résultat #ENV*{postname} et #ENV**{postname}, et je me suis rabattu pour l’instant sur un très vilain :

<h4>Sont déjà inscrit(e)s au poste #ENV{postname}&nbsp; pour le créneau #ENV{time}</h4>

Qu’est-ce qui est à l’origine du fait que l’espace qui suit la balise soit mangé sans autre forme de procès ?

Tu écris « Pour une raison qui m’échappe #VOIR_REPONSE{hidden_2,valeur_uniquement} renvoie <p>xxh-yyh</p> »
Alors

  • soit c’est le fonctionnement de #VOIR_REPONSE : tu as essayé les autres valeur de paramétrage que valeur_uniquement ?
  • soit c’est que toi tu ajoutes ces tags. Là il faut voir ton squelette et ce que tu mets dans le hidden.

Quant à « la valeur de #ENV{postname} est collée au mot suivant », c’est normal, toutes les balises mangent les espaces autour d’elles. Pour éviter cela il faut utiliser la syntaxe avec crochets parentheses, qui protège les espaces inclus dans les crochets et les espaces voisins en dehors des crochets.
Donc par exemple « valeur de [(#ENV{postname})] n'est plus collée ainsi ».

Non, non, c’est SPIP qui paragraphe de sa propre initiative (voir plus haut le code du squelette dans lequel il n’y a pas de <p>)