Quelques bugs sur le formulaire de soumission

Plus gênant : le champ “lien réciproque” n’est pas obligatoire sur le formulaire alors qu’il est paramétré comme tel…

– Pour Google Recaptcha, il y a deux choses. Link Library support reCaptcha v2 en ce moment, et non v3. Aussi, le captcha n’est pas affiché pour les usagers inscrits au site.
– Le champ téléphone requis est corrigé dans la version 6.7.2
– Je ne comprends pas le point sur la balise image en trop.
– Pour les étoiles pour les champs requis, il est possible d’ajouter une étoile dans le champ label de chaque champ, tel que désiré. Je ne voulais pas ajouter un truc que certains gens allaient vouloir enlever.
– En effet, le générateur de screenshot ne tourne pas quand les usagers soumettent des liens. Comme la plupart des gens veulent regarder les liens soumis avant de les afficher, je me suis dit que les gens allaient pouvoir générer l’image et la valider avant de rendre le lien visible. Aussi, plusieurs générateurs d’images affichent une image générique “lien en génération” si ce n’est pas un site dont l’image a déjà été générée. Il n’est probablement pas désirable d’avoir une image non revue affichée sur le site.
– Le champ lien réciproque requis est corrigé dans la version 6.7.2

Merci pour ta réponse.
Pour la version du Captcha, ok je comprends. Mais je crois que le captcha “maison” (une question) ne s’affiche pas non plus.
Les étoiles : effectivement je n’y avais pas pensé…
Le screenshot, pas de problème: je vais leur faire uploader une image (y-a-t-il un contr?le de taille et de type à la soumission ?).
Quand la V6.7.2 sera-t-elle disponible ?
Et pour le coup de “l’image en trop”, c’est dans l’affichage de l’annuaire, dans un certain type de config dont je ne me souviens plus, je l’ai résolu en insérant des BR, tout va bien.

La 6.7.2 est maintenant disponible. Pour le captcha maison, il devrait aussi s’afficher seulement pour les visiteurs non connectés. Oui, il y a un controle de type pour les images. Le controle de taille se fait selon la configuration générale des uploads du site.

Génial! Merci et bravo pour ton super boulot !

Merci d’avoir trouvé ces problèmes et d’avoir pris le temps de les rapporter. Svp veuillez considérer de faire un don pour supporter le développement de ce plugin. Salutations de Montréal ??

Bonjour, oui je vais faire un don avec plaisir !
Mais avant cela j’aimerais résoudre ces deux points :

– Que faut-il faire pour afficher le Captcha “phrase” ? J’ai supprimé mes clés ReCaptcha mais cela ne fonctionne pas pour autant. Dans le formulaire de soumission, j’ai mis “Affiche” à “Question de captcha personalisée”. Que faire ?
– Il y a des erreurs de traductions sur la gestion des erreurs du form soumission : The input value is not a correct URL. Requires https:// or https://.
J’ai édité le PO Fran?ais et régénéré le FR.mo mais ?a ne change rien.
Merci !

Je note aussi que ces deux champs :
– Nom de l’utilisateur ayant soumis le lien
– E-mail de l’utilisateur ayant soumis le lien
Bien que paramétrés obligatoires ne sont pas bloqués par la vérification du form.

Après vérification : effectivement ces 2 champs + captcha sont visibles si on se déconnecte de l’admin…
Restent ce petit problème de traduction et la vérif du champ captcha personnalisé qui est “Champ obligatoire type=”

Bon, je refais un point. C’est un peu laborieux…

1- Il y a un problème avec les “\” d’échappement des apostrophes dans les champs textes et textarea (front et admin)
2- Je viens de voir, en testant, que le formulaire de soumission est en GET. Comment ?a va se passer avec le champ “description longue” ? On risque d’atteindre la longueur maximale d’une URL…

Bonjour Renaud, Allons-y.

– Pour l’affichage de la phrase de Captcha personnalisé, on n’a qu’a choisir de l’afficher. Encore la, elle ne s’affiche pas pour les usagers enregistrés. Si tu ouvre une fenêtre incognito, tu devrais voir ta question personnalisée.

– J’ai corrigé la traduction de The input value is not a correct URL. Requires https:// or https:// dans la version 6.7.3.

– Pour les champs obligatoires non bloqués, corrigés dans la 6.7.3, disponibles dans quelques moments. Tous ces champs étaient des erreurs de copier-coller qui datent déjà de plusieurs années. Surpris qu’ils n’aient jamais été trouvés. Et en effet, les champs de nom d’usager et de courriels ne sont pas affichés si l’usager est connecté, puisque l’on a deja ces informations.

– Le message champ obligatoire type= est réglé dans la 6.7.3.

– Pour les échappements de texte, je vais devoir passer un peu plus de temps sur cette problématique.

– Pour le formulaire en mode get, je n’ai pas le choix selon la fa?on ou les données sont gérées par WordPress. La fonction wp_redirect ne permets pas de redigiriger en POST.

Bonsoir Yannick c’est cool que tu aies fait ces modifs !
Par contre ?a me gêne vraiment, le coup du GET, parce que je veux justement inciter les gens à soumettre des liens de qualité, avec une belle description fournie et tout ?a…
Je vais pas te faire refaire tout ton plugin, d’autant qu’il est gratuit et que c’est un chouette boulot…mais ce serait compliqué de balancer les données dans une table SQL de suite après la soumission (avant tous les headers) avec un add_action ‘template_redirect’ puis ensuite un safe_redirect pour message d’erreur ou de succès ?

Les gens arrivent seulement sur ce lien en GET si ils ne remplissent pas un truc ou si ils manquent le captcha. Si tout est bien rempli, c’est soumis avec un POST. Mais en effet, je pourrais stocker les informations dans un champ temporaire dans la DB au lieu de tout renvoyer un GET. Je vais explorer cette idée dans les prochains jours.

Ce serait génial ! Tu as déjà les contr?les JS sur le form qui empêchent pas mal les erreurs…Mais si tu parles de réafficher les données dans les champs quand il y a eu erreur, il y a la table temporaire mais aussi les sessions… Pour le captcha j’ai viré le contr?le par image et mis la phrase. Si le contr?le de la réponse est insensible à la casse, ?a devrait le faire.

Bonjour Yannick, merci pour la V6.7.3 qui corrige un certain nombre de bugs.
Les traductions des messages d’erreur n’ont pas changé : “The input value is not a correct URL. Requires https:// or https://.”
D’ailleurs le “requires…” est inutile puisque le préfixe est déjà dans le champ en valeur défaut.
J’en profite pour dire que tu devrais remplacer les <span> par des <div> dans le jquery.form-validator.js , dans cette ligne :
$mess = $('<span></span>').addClass('help-block').addClass(conf.errorMessageClass);
Comme cela le message d’erreur s’affiche sous le champ et non à c?té, ce qui est bien plus esthétique.

Je note encore que le champs “user tags” ne s’affiche pas bien qu’il soit à “Permettre”.
Et l’email que re?oit la personne qui soumet son lien est à revoir (si je peux t’envoyer un mail je te le fais suivre)
Voili voulou, bon courage !