Bonjour,
Je me permet ce petit mail au sujet de la révision 13939 : http://trac.rezo.net/trac/spip/changeset/13939
Suite à cette révision deux formulaires CVT que j’ai développés ne fonctionnaient plus comme dans la version précédente voir ne fonctionnaient plus du tout.
Pour l’un des formulaires le problème était le suivant : la fonction xxx_verifier_dist(){} dès lors qu’elle était présente obligeait les utilisateur à soumettre une première fois le formulaire à blanc avant que celui-ci ne daigne fonctionner normalement.
Je n’a malheureusement pas fait d’investigation sur le second formulaire. Car suite au roll back des fichiers modifiés dans cette révision dans leur version présente en 2.0.7 révision 13901 il s’est remis à fonctionner normalement.
Mes autres formulaires fonctionnaient normalement. La particularité de ces deux formulaires est d’effectuer un test dans “charger_dist” pour empêcher un utilisateur de remplir deux fois le même formulaire. (je renvoie un ‘editable’ = false et un ‘message_erreur’ dans charger_dist() si le formulaire a déjà été remplis).
Si vous avez besoins de plus d’info n’hésitez pas à me contacter,
Meilleures salutations, et merci pour le travail que vous effectuez sur SPIP.
Vinz
Bonjour, et merci de ce retour.
Sans plus de précisions il va être difficile d'en savoir plus, mais déjà une question : est-ce que ce bug est toujours présent dans la version 2.0.9 svn ?
Dans le cas contraire il faudrait disposer soit du code du formulaire, soit connaître les spécificités de ton code puisque c'est le premier cas, à ma connaissance qui se présente et on peut difficilement deviner ce qu'il se passe.
Bien chaleureusement,
Il faut que tu donnes toutes les infos.
Le mieux serait l’url de la page ou voir le formulaire defectueux, car je pense que c’est un probleme de conversion url → input hidden, qui fait que au premier submit l’url vue par le formulaire change, et du coup il considère que ce n’est pas lui qui a été posté.
Le type de problème qui peut poser cela est aussi d’avoir en saisie un parametre de meme nom qu’un des arguments de la chaine de get de l’url.
Il serait bien que l’on puisse verifier le problème pour voir si il vient d’un bug de la fonction apres correction, ou si le bug etait avant (et le fait que ça marche un coup de chance !).
Sinon, pour ce type de cas, il est possible de forcer la prise en compte du submit en indiquant, dans le tableau renvoyé par charger :
‹ _forcer_request › => true
cf http://www.spip.net/fr_article4151.html (que je viens de publier :p)
Cédric