Cette documentation est valable à partir de la version 6.1.0 de Formidable.
Introduction
Historiquement, deux plugins avaient déjà été développés précédemment pour gérer des formulaires :
- Forms &Tables, qui n’a pas été complètement porté pour SPIP 2.
- et spip-formulaire créé par artego mais qui n’était plus maintenu.
La question s’est donc posée : construire sur la base d’un des deux plugins ou repartir de zéro ?
Form &Table, très complet pour les utilisateurs, présentait l’inconvénient d’avoir un côté “fourre-tout” qui le rendait difficilement modifiable et difficile à personnaliser par les dévs.
Il a finalement été décidé de repartir de zéro pour proposer quelque chose:
- de plus facile à utiliser pour les utilisateurs d’une part,
- mais aussi de plus facile à personnaliser pour les développeur⋅euses.
Avec le parti pris de se baser de préférence sur plusieurs petits plugins spécialisés et de tirer parti de la nouvelle norme CVT.
Interface utilisateur
triceL’utilisation basique de l’interface est abordée dans ce screencast : Mon premier formulaire pas à pas : c’est Formidable !
Appeler mon formulaire
Vous devez appeler le formulaire ayant le nom “formidable”, en lui passant en paramètre l’identifiant de votre formulaire.
Dans un contenu
Utilisez le modèle <formulaire>
classique : <formulaire|formidable|id=34>
ou bien <formulaire|formidable|id=contact>
Dans un squelette
#FORMULAIRE_FORMIDABLE{34}
ou bien #FORMULAIRE_FORMIDABLE{contact}
Afficher les résultats du formulaire
Dans un contenu
Utilisez le modèle <formulaire_analyse|id_formulaire=34>
Pré-remplir dynamiquement les champs d’un formulaire
À noter, vous avez la possibilité de surcharger dans l’appel, les valeurs par défaut des champs de votre formulaire. Pour cela, vous devez passer un tableau de nom=>valeur
en deuxième paramètre. Vous pourrez trouver les noms de vos champs dans l’aide-mémoire situé sur la page de configuration des traitements.
Dans un contenu
Le tableau de valeurs dans un paramètre defaut sous forme d’une suite de chaînes “clé,valeur” séparée par des virgules :
<formulaire|formidable|id=contact|defaut=hidden1,valeur,input_5,autrevaleur>
Dans un squelette
Le tableau en deuxième paramètre :
#FORMULAIRE_FORMIDABLE{contact, #ARRAY{nom_du_champ, Ma valeur}}
C’est particulièrement utile pour remplir un champ caché avec une valeur dynamique venant du squelette :
#FORMULAIRE_FORMIDABLE{contact, #ARRAY{hidden_1, #ID_DOCUMENT}}
Autres options utilisable dans le squelette
Il est possible de passer des options comme troisième argument du formulaire, sous forme de tableau (#ARRAY
).
Nom de l’option | Fonction | Type |
---|---|---|
forcer_modif |
Permet de forcer la modification d’une réponse, même si non autorisé | Booléen |
id_formulaires_reponse |
Identifiant de la réponse à modifier | Entier |
no_ajax |
Désactiver l’ajax sur le formulaire | Booléen |
traiter_enregistrement_desactiver_modif_instituer_prop |
Permet de désactiver au cas par cas l’option de configuration « Lorsque l’internaute modifie la réponse, son statut redevient « proposée » » | Booléen |
traiter_email_destinataires |
Destinataires pour le traitement | Tableau (#ARRAY ) d’emails ou liste d’emails séparés par des virgules |
traiter_email_destinataires_methode |
Indique si traiter_email_destinataires doit remplacer les emails déjà configurés dans le traitement ou les ajouter |
Au choix 'remplacer' ou 'ajouter' (valeur par défaut) |
url_redirect |
Url de redirection | Chaine |
Exemple d’un formulaire Formidable dont l’identifiant est contact_libre et dont l’email destinataire est dans le champ email de la table de votre objet #EMAIL de la table spip_contacts …
.
<div class="ajax">
#FORMULAIRE_FORMIDABLE{contact_libre,'',#ARRAY{traiter_email_destinataires,#EMAIL}}
</div>
Case unique
Pour rendre obligatoire la réponse oui à une case unique (pour la validation de conditions d’utilisation par exemple), il faut simplement rendre le champ obligatoire.
Courriels de notification
Une option des traitements proposés permet d’envoyer un mail de notification automatiquement, à chaque saisie d’un formulaire.
Le squelette par défaut employé pour la mise en forme de ces mails est plugins/formidable/notifications/formulaire_email.html
. Vous pouvez le copier dans le répertoire ’notifications’ de votre squelette et l’y modifier à votre guise. Cette modification vaudra pour tous les formulaires.
Pour utiliser un squelette spécifique pour les mails de notification de l’un seulement des formulaires définis avec Formidable, il suffit d’ajouter son squelette dans le répertoire ’notifications’ de votre dossier squelettes, mais en ajoutant l’identifiant.
IDENTIFIANT étant l’identifiant du formulaire défini dans Formidable, les squelettes doivent se nommer :formulaire_IDENTIFIANT_email.html
pour le mail aux destinatairesformulaire_IDENTIFIANT_accuse.html
pour l’accusé de réception du visiteur
Conservation des IP
Les adresse IP des personnes répondant aux formulaires sont stockées en base de donnée. Depuis la version 1.5 (SPIP 3) / 0.7 (SPIP < 3), elle sont automatiquement hashé, de manière à ce que l’IP ne soit plus reconnaissable, au bout de 124 jours (environ 4 mois).
Pour changer ce délai, vous pouvez redéfinir la constante _CNIL_PERIODE
dans votre fichier mes_options.php
.
Par exemple :
define('_CNIL_PERIODE', 24*3600);
permet de hasher les IP toutes les 24 heures.
Si vous voulez désactiver le hashage, mettez la valeur à 0.
Envoi de fichiers
Lire l’article complémentaire : Envoyer des fichiers avec un formulaire Formidable.
Mise en forme des saisies
Le plugin ne prévoit aucun réglage de mise en forme des saisies : c’est à chaque squelette d’avoir ses styles. Il respecte cependant la convention d’écriture des formulaire SPIP. Il permet d’ajouter des classes spécifiques sur les saisies.
Affichage des réponses sous forme de tableau
Le plugin Formidable Tablesorter permet d’afficher sous forme de tableau les réponses, dans l’espace privé, avec possibilité de tri et de filtre.
Voir aussi sur le wiki
- Complément de doc et exemples sur les boucles et balises de formidable
- Exemples de stylage CSS d’un formulaire Formidable
- todoFormidable
- Formidable, présentation aux Grottes (2010)
Discussions by date of activity
830 discussions
Bonjour,
J’essaie de faire un formulaire de contact qui permette de garder secrets les courriels des personnes de notre annuaire professeur (certains utilisent des adresses personnelles).
Les personnes inscrites n’ont pas toutes des comptes auteurs aussi ai-je enregistré les adresses de contact dans le champ “Description brève” de leurs fiches. L’idée est donc de transférer la valeur de cette Description brève dans un champ caché du formulaire et de l’utiliser comme adresse de destinataire.
J’ai intégré le formulaire dans le squelette des fiches de membres, avec l’appel
(j’ai mis PtoBR pour éviter le risque d’ajouts de balises HTML perturbatrices)
Sauf que je ne parviens pas ensuite à récupérer la valeur pour l’injecter correctement. J’ai même essayé en saisissant directement une adresse électronique lors de l’appel du formulaire. J’ai aussi essayé
Est-ce que cette manip n’est tout simplement pas faisable ? Ou, s’il faut manipuler un autre squelette, où puis-je le trouver ? Je n’ai pas réussi à trouver formulaire_contact dans les dossiers...
Merci de votre aide,
Alexis
Qu’entendez vous par “fiche” ?.
Par ailleurs je vous invite à relire la doc juste au dessus
1. Vous verrez que la première option d’appel au formulaire correspond aux valeurs par défaut des champs du formulaire. Or
a. Il n’y a pas de champ
courriel_cache
dans le formulaire (cf les noms de champs listé à droite lors de la config des traitements !)b. Quand bien même un tel champ existerait, votre appel revelerez publiquement les emails, en rajoutant leur nom dans le code html
2. Il existe la possibilité de passer un second tableau d’option, dont l’une des options est
traiter_email_destinataires
pour indiquer les destinataires lores du traitementemail
La fiche de membre est la rubrique qui lui est consacrée, avec un ou plusieurs articles de présentation. C’est dans le premier article, qui est obligatoire, que j’ai enregistré le courriel dans le champ “Description brève” (donc #DESCRIPTIF dans les boucles) afin de l’avoir en référence (parce que cet article, obligatoirement page d’accueil de la rubrique, n’a pas l’usage de DESCRIPTIF, me permettant d’en détourner l’usage).
Je n’ai pas bien saisi le comportement de “traiter_email_destinataires”, ce qui fait que je n’ai pas essayé de l’utiliser.
De ce que j’ai compris, il s’agirait donc d’intégrer
{traiter_email_destinataires, #DESCRIPTIF|PtoBR}
comme argument de l’appel du formulaire, mais ce que je ne parviens pas à trouver dans la documentation (ni dans l’interface d’édition du formulaire), c’est comment j’indique ensuite au formulaire de l’utiliser. Est-ce automatique et je cherchais comment l’intégrer pour rien ? Ou est-ce qu’il y a encore quelque chose qui m’échappe ?Bah dans formidable une fois qu’on a créé les champs d’un formulaire, on doit configurer des traitements. Parmis ceux-ci, il est possible de d’activer le traitement “Envoyer par email”. Si vous activez ce traitement, et bien ensuite tout les emails passé comme argument via
traiter_email_destinataires
seront ajoutés comme destinataires...Merci pour la confirmation.
En préparant ma réponse parce que ça ne marchait pas, j’ai constaté qu’un caractère vide était intégré dans mon code (le copier-coller affichait ceci :
ARRAY{-traiter_email_destinataires
, mais totalement invisible dans NotePad++), ce qui faisait bugger l’appel à cet argument.Maintenant que je l’ai retiré, ça marche en effet directement.
Merci beaucoup,
Alexis
Super. Pour l’avenir, peut tu utiliser la balise code ou les backsticks lors que tu cite du code ? cela évite de perdre les
}
et autres caractères spéciaux...J’essaierai d’y penser, oui. :-)
Reply to this message
Bonjour,
Je cherche à construire le tableaux de réponses à un formulaire.
Je suis en SPIP 4.4 et formidable 7.0.6.
Comme indiqué dans Complément sur Formidable, j’ai une boucle pour afficher les labels dans la ligne de tête :
Mais cette boucle ne me renvoie rien.
Si je mets #SAISIES dans la boucle, ça ne renvoie rien.
Quelle serait les bonnes balises pour afficher les labels ?
Merci.
La doc
complement sur formidable
n’a jamais vraiemnt été “approuvée” par les auteurs de formidable, Ce sont plus des essais fait par des gens et mis dans une doc pas forcément pensé de a à z.Il se trouve que depuis la rédaction de cette doc, formidable a modifié la manière de stocket en interne les saisies. Il faut remplacer
unserialize
parformidable_deserialize
et cela devrait marcher (/(sur ce point du moins).Merci Maïeul, ça fonctionne avec
formidable_deserialize
!Je dépose le code SPIP de mon tableau de résultats :
Reply to this message
Bonjour,
depuis la dernière màj de Formidable, les mails ne partent plus. J’ai systématiquement le message d’erreur du plugin.
Les mails partent bien à partir du test du Facteur (par SMTP, via un compte sur le domaine). Tout est à jour (Spip 4.4.2) et plugins.
J’ai ce problème chez Ionos et Infomaniak.
Je joins le yaml sur demande. Tout fonctionnait bien avant...
D’avance merci pour votre aide,
Rémy
Les plugins facteurs et le cas écheant mailshot sont-ils bien à jour ?
Bonjour,
Facteur 5.2.1 et Mailshot n’est pas installé.
Merci
Bon, je poursuis mes tests sur différents sites avec les mêmes versions de plugins. Certains sont sous Spip 4.3.8, d’autres en 4.4.2. Chez Hostinger, j’ai aussi le même souci : les mails ne partent pas. Les réponses s’enregistrent bien en base, Facteur fonctionne normalement. Les configurations sont identiques.
Hum. Donc oui c’est bon.
Je ne sais pas. Il faudrait que je puisse debuguer en live en disposant d’un accès au privé et des accès ssh... Chez moi ca marche TM.
Bonjour,
j’ai continué mes tests en comparant les réglages de chaque formulaire, quel que soit l’hébergeur. Je n’ai rien trouvé de ce côté. Les seules différences se situent au niveau du Facteur, avec plusieurs cas de figure (fonction mail php, smtp, Mailjet). Dans tous ces cas, les mails partent bien depuis le Facteur.
En installant Formidable (7.0.5) sur un site perso (4.4.2 / php 8.3) qui n’utilise pas le plugin, j’ai créé un formulaire et celui-ci fonctionne parfaitement (mail admin + internaute). C’est bien une nouvelle installation et non une màj.
J’ai donc fait le test suivant : exporter un yaml d’un formulaire, supprimer le formulaire, supprimer Formidable. Puis, j’ai réinstallé Formidable et importé le yaml. Malheureusement l’erreur est toujours présente. Sur ce même site, j’ai créé un nouveau formulaire : erreur également :-(
Je ne peux que constater que les versions après la 6.6.2 donnent tous la même erreur quand il y a eu màj.
Peut-on se caler pour essayer de résoudre le problème ?
Merci pour ton aide, parce que là j’ai les 2 pieds dedans...
Rémy
Essaie de me biper sur discord (dans l’idéal) ou à la rigueur IRC (mais je suis même réactif) dans la journée. On peut essayer de voir cela.
Merci pour ton temps. Je ne suis par sur Discord et je ne sais pas utiliser Irc...
Je serai plutôt dispo demain, si tu l’es également ?
Non je ne suis pas dispo demain, ni toutes les 2 prochaines semaines...
Ok, je peux être dispo maintenant pour maxi 30mn. Ok pour toi ?
Bah oui mais faut que tu me contacte...
Je t’envoie un mail, merci !
Eh bien, un GRAND MERCI à Maïeul pour avoir résolu le problème.
Il suffisait de décocher la case “Insérer l’adresse d’envoi dans le champ “From”” dans les traitements du formulaire pour que ça fonctionne.
J’ai testé sur plusieurs formulaires, avec des méthodes d’envoi différentes, chez plusieurs hébergeurs : c’était bien ça qui coinçait !
Si ça peut servir à d’autres :-)
Bon dimanche,
Rémy
Reply to this message
bonsoir,
cette fois, j’ai fait ma première pétition avec formidable.... avec un modèle pour afficher les signataires dans la partie publique.
le tableau des résultats est parfait pour gérer les signatures..
il reste une fonction que je ne sais pas faire...
Comment importer les données d’un tableau dans un formulaire... ?
Pour mon cas de pétition, j’ai en effet des signatures qui n’ont pas été saisies en ligne et qui me son transmises sous forme de tableau...
une idée ?
Malheureuement non on n’a pas encore de fonctions d’import. Ca fait partie d’une todoliste depuis longtemps.
Et je pense que tu a compris en codant ton modèle (félicitation) pourquoi ce n’est pas si simple que cela d’avoir un modèle generique d’affichage des réponses d’une petition.
Reply to this message
bonsoir
j’avais tenté dans le passé de faire développer un plugin de pétition amélioré, qui n’a pas survécu à l’évolution de spip et notamment à spip4
et de toute façon, formidable est tellement formidable, que tout peut se refaire avec...
j’ai créé mon premier formulaire formidable, ca marcne, il y a des signatures en ligne, mais je m’aperçois que ce n’est pas simple du tout de faire qqchose qui parait simple avec la pétition standard de spip, un modèle d’affichage des résultats dans la partie publique (donc en choisissant les données à publier...)
J’ai vu qu’il y avait tablesorter mais pour le coup, c’est beaucoup trop pour le besoin simple d’un tableau paginé dans un modèle.
je vois que le modèle formidable analyse propose un affichage, mais pas du tout orienté vers une liste de signataires...
est-ce que j’ai raté qq chose ?
merci d’avance
Je ne pense pas, effectivement. Il n’y a pas pour l’instant un truc adapté à ton besoin directement.
j’ai avancé, en faisant un modèle reposant sur une boucle FORMULAIRES_REPONSES et une FORMULAIRES_REPONSES_CHAMPS, qui me permet d’avoir la liste des valeur saisies par réponse.
c’est primitif et surtout, ca fait un modèle pour un formulaire précis, mais c’est un premier pas...
encore un petit pb, ca ne veut pas générer un tableau spip malgré les “|”... ???
et il faudrait ajouter la date de la réponse, qui ne semble pas être un champ
et paginer...
voila le code
j’ai ajouté la date avec
je ne sais pas pourquoi on ne peut pas ajouter le filtre addate directement dans le tableau...
voila le modèle final avec pagination
idéalement, il faudrait pouvoir sélectionner les champs à afficher et pouvoir les mettre dans un certain ordre...
Reply to this message
Bonjour,
Nouveau sujet ici pour éviter les mélanges de sujets : je vois que l’on peut exporter les résultats d’un formulaire, mais je me demande si l’on peut réimporter ces résultats (pour chaque formulaire) sans forcément toucher à la base de données (j’avoue ne pas oser) ?
L’idée étant de ne pas perdre les réponses des internaudes et leurs validations RGPD, lors de grosses modification d’un site en local, sans perdre les données récentes issues des formulaires qui elles, arrivent tous les jours sur le site en production…
D’avance merci pour vos retours et éclairages.
Bonne semaine :)
Reply to this message
Bonjour,
Je poste ici car c’est un problème qui est survenu depuis l’avant-dernière mise à jour du plugin, que j’ai faite ce mardi, et idem avec la dernière mise à jour d’aujourd’hui 7/02, même problème :
Mon module d’abonnement à des listes de diffusions (grâce au plugin du même nom et non modifié) ne fonctionne plus depuis la mise à jour du plugin Formidable. C’est une page blanche pour le visiteur et l’information remontée en debbugage de SPIP rapporte l’erreur suivante :
Erreur(s) dans le squelette :
L111: formulaires_formidable_saisies_set_options(): Argument #3 ($valeurs) must be of type array, string given, called in D:\SERVER\wamp64\www\adn-4-3-test\plugins\auto\formidable\v7.0.1\formulaires\formidable.php on line 97
Est-ce que quelqu’un d’autre qui utilise l’abonnement aux listes aurait le même problème, et/ou comment le résoudre ? Je n’en ai pas les compétence.
Je précise que je n’ai rien modifié dans les modèles, et que mes autres formulaires fonctionnent toujours.
D’avance merci pour vos remontées et/ou aide.
Bonne journée
Bonjour,
peux-t-on avoir un export yaml du formulaire en question ?
Je poste le code de l’export directement ? Car je ne crois pas pouvoir joindre un fichier yaml…?
tu peux me l’envoyer a monprenom@monprenom.net
C’est fait, avec un i normal à la place du ï… :)
Bonjour,
Pour info j’ai eu ce problème et cela venait du code d’inclusion de mon formulaire :
j’avais
#FORMULAIRE_FORMIDABLE
(il prenait automatiquement le seul formulaire créé)
en mettant :
#FORMULAIRE_FORMIDABLE{1}
cela refonctionne.
dd
@Karen le problème venait de l’appel dans le corps de l’article.
Tu as mis
<formulaire|formidable|id=inscription_newsletter|listes=newsletter_inscriptions>
or la bonne syntaxe (cf le corps de l’article) est le suivant
<formulaire|formidable|id=inscription_newsletter|defaut=listes,newsletter_inscriptions>
en corrigeant cela tout remarche.
hum non il y a quand meme un problème, même avec cette syntaxe. Mais j’ai trouvé pourquoi.
Génial, merci Maïeul, ça fonctionne très bien à présent.
Juste une info toutefois, j’ai testé ta syntaxe :
Et cela fait que l’internaute qui s’inscrit ne reçoit pas le mail à valider pour finaliser son inscription.
J’ai donc conservé “ma” syntaxe :
Et tout fonctionne parfaitement grâce à ta mise à jour. Merci pour ton temps et ton partage.
Ta syntaxe ne sert strictement à rien. Elle ne permet pas l’inscription. Je regarde pour le problème avec la vraie syntaxe, la seule officiellement supportée (et supportable).
Je regarde pourquoi tu a le problème.
Hum,
je ne comprend mmeme pas comment ta syntaxe aurait pu marcher. Mais la mienne non plus.
La bonne syntaxe c’est celle là
<formulaire|formidable|id=inscription_newsletter|defaut=listes_diffusion_1,newsletter_inscriptions>
pour dire de cocher par défaut la liste
newsletter_inscription
.Cela étant si tu n’a qu’une seule liste, tu pourrais très bien simplifier tout cela en
1. Supprimer la sisie de choix de liste dans le formulaire
2. Mettre à la place un champ caché contenant l’idnetifiant de la newsletter et dire qu’on s’appuie sur ce champ dans la configuration du traitement
3. Appelerr directement le formulaire.
@Maïeul, un grand merci, et effectivement ça fonctionne super avec cette syntaxe et les corrections que tu as apportées :D
Oups, erreur et je ne sais comment supprimer mon message !
…
Reply to this message
Bonsoir,
J’ai créé un simple formulaire avec un champ pour le nom, l’email et un bloc de texte (textarea). Le message de confirmation arrive bien chez l’expéditeur, en revanche, moi, en tant que destinataire, je ne reçois rien.
Ai-je oublié quelque chose ? mais ou !
Merci
Sinon, est-il possible d’afficher des * pour indiquer les champs obligatoires à la place du texte “obligatoire” ?
Merci à vous.
Un export yaml du formulaire permettrait de savoir ce qu’il en est...
pour ce qui est du
*
c’est possible mais il faut bien indiquer au départ que les * signifie obligatoire pour des raisons d’accessibilités.Voir https://romy.tetue.net/signaler-les-champs-obligatoires (hors ligne pour le moment mais archive ici http://web.archive.org/web/20200627035051/http://romy.tetue.net/signaler-les-champs-obligatoires)
Je vous conseil donc de laisser tel quel.
Bonsoir
Les fichier yaml ne sont pas acceoté a l’envoie.
Le symbole * eviterai les traductions en plus, car ce sera un site multilangue
Merci
Chrys
Spip traduira automatiquement l’information alors.
Je regarderai les détails du yaml ce week-end.
Excellent, je ne savais pas pour les traductions.
Et merci pour la révision de mon fichier.
Bonne soirée
Bonjour Maïeul, j’ai trouvé entre-temps en faisant des tests en ligne. Merci.
Parfait alors
Reply to this message
Bonjour
J’ai un (vieux) formulaire sur l’un de mes sites web qui utilise le champ “oui_non” qui est maintenant obsolète.
Il est utilisé de façon à ce que les personnes identifiées puissent modifier leur réponse.
Je ne saurai pas dire depuis quand, mais les réponses des champs “oui_non” ne se chargent plus. Les autres champs se chargent bien avec la réponse précédente.
C’est assez ennuyeux.
Comment rectifier mon formulaire ? Si je supprime les champs “oui_non” pour les remplacer par des champs “radio”, je vais perdre les données saisies par les gens, ce n’est donc pas une option.
Merci de votre aide
Peux tu fournir un export de ce formulaire. C’est un pur bug d’affichage, Les saisies obsolètes sont censées toujours etre disponibles à l’affichage, juste plus étendue/améliorée.
(il n’y a pour l’heure pas de manière simple de convertir des types de saisies)
J’ai essayé de reproduire et je n’ai pas de problème. Mais je ne suis pas sur de comprendre ce que tu veux dire par “les réponses ne se chargent plus”. Peut tu me décrire précisement les étapes?
Reply to this message
Bonjour
Avec Spip 4.3.6, depuis que je suis passé à Formidable 7, et 7.1 je rencontre le pb suivant :
- dans le traitement des formulaires, j’ai choisi “Envoyer un courriel à des responsables”.
- dans “Adresses de destination”, j’ai saisi l’adresse voulue.
- dans “Sujet”, j’ai saisi : “MonTexte : 9-@input_1@”
- mais le mail reçu contient le sujet : “Machin vous a écrit”.
Il s’agit de formulaires écrits avant la mise à jour de Formidable : et à l’époque leur sujet reprenait bien ce que j’indiquais.
Une idée ?
Merci.
Bonjour,
formidable 7.1 n’existe pas. Je pense que vous parlez de formidable 7.0.1
Dans tous les cas lorsqu’il s’agit de signaler un bug formidable, un export yaml sera très utile pour comprendre plus précisement où se trouve le problème.
Fichier Yaml envoyé.
Ensuite, comme ce formulaire est une “duplication” d’un autre - sans autre changement que le choix des cases à cocher - j’ai comparé les champs “traitements” via PhpMyAdmin : j’y ai vu des différences (cf image jointe).
J’ai remplacé le contenu du champ “traitements” du formulaire KO par celui du formulaire OK, et le “sujet” du courriel est redevenu celui attendu.
Mais je ne sais pas pourquoi les traitements avaient changé...
La version “Master” du plugin corrige cela. Je sortierai une version officielle tantot, je dois encore debuguer un truc.
Et donc la version 7.0.2 résoud le problème.
OK,
Merci.
Reply to this message
Add a comment
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
Merci d’avance pour les personnes qui vous aideront !
Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.
Follow the comments:
|
