Le 21/10/2009 21:55, marcimat@free.fr a écrit :
Author: marcimat@free.fr
Date: Wed Oct 21 21:55:03 2009
New Revision: 32267
Log:
New n'est pas top encore… On met «oui» pour que «exemple» puisse être récupérer comme avant.
'oui' non plus n'est pas top.
Il me semble que depuis l'écran de sécurité, on avait dit que tous les $id_truc devaient obligatoirement contenir des entiers. Là dans ce cas c'est pas un paramètre d'URL, mais à mon avis peu importe, il vaut mieux ne plus montrer cet exemple pour ne pas porter à confusion (= "bonne pratique").
--
RastaPopoulos
Le 22/10/2009 06:34, RastaPopoulos a écrit :
Le 21/10/2009 21:55, marcimat@free.fr a écrit :
Author: marcimat@free.fr
Date: Wed Oct 21 21:55:03 2009
New Revision: 32267
Log:
New n'est pas top encore… On met «oui» pour que «exemple» puisse être
récupérer comme avant.
'oui' non plus n'est pas top.
Il me semble que depuis l'écran de sécurité, on avait dit que tous les
$id_truc devaient obligatoirement contenir des entiers. Là dans ce cas
c'est pas un paramètre d'URL, mais à mon avis peu importe, il vaut mieux
ne plus montrer cet exemple pour ne pas porter à confusion (= "bonne
pratique").
C'est en fait très complexe finalement, et le core de SPIP est un peu responsable je trouve à ce truc mal fichu :
- les formulaires d'édition de SPIP utilisent 'new' par défaut en absence de valeur MAIS cette valeur est transformée en 'oui' dans une des fonctions d'appel formulaire_editer_objet_xx.
- cela a pour conséquence que la valeur des arguments du formulaire (id_ticket et url) postés n'est pas systématiquement les même à la création d'un objet #FORMULAIRE_EDITER_TICKET{#ENV{id_ticket}} et que du coup la variable $je_suis_posté de balise/formulaire_.php ne considère pas le formulaire comme étant soumis.
- pour éviter cela, il faut que toutes ces valeurs soient identiques entre l'appel du formulaire et la soumission. 'oui' pour id_ticket est donc la valeur qu'il lui faut pour fonctionner (je dis pas que c'est le mieux) #FORMULAIRE_EDITER_TICKET{#ENV{id_ticket,oui}}.
Et là intervient l'écran de sécurité en prime… j'ai pas regardé ce qu'il se passait avec lui. J'espère que ça passe.
--
MM.
Le 22/10/2009 08:28, Matthieu Marcillaud a écrit :
C'est en fait très complexe finalement, et le core de SPIP est un peu
responsable je trouve à ce truc mal fichu :
- les formulaires d'édition de SPIP utilisent 'new' par défaut en
absence de valeur MAIS cette valeur est transformée en 'oui' dans une
des fonctions d'appel formulaire_editer_objet_xx.
- cela a pour conséquence que la valeur des arguments du formulaire
(id_ticket et url) postés n'est pas systématiquement les même à la
création d'un objet #FORMULAIRE_EDITER_TICKET{#ENV{id_ticket}} et que du
coup la variable $je_suis_posté de balise/formulaire_.php ne considère
pas le formulaire comme étant soumis.
- pour éviter cela, il faut que toutes ces valeurs soient identiques
entre l'appel du formulaire et la soumission. 'oui' pour id_ticket est
donc la valeur qu'il lui faut pour fonctionner (je dis pas que c'est le
mieux) #FORMULAIRE_EDITER_TICKET{#ENV{id_ticket,oui}}.
Et là intervient l'écran de sécurité en prime… j'ai pas regardé ce qu'il
se passait avec lui. J'espère que ça passe.
Que ce soit GET, POST, ou GLOBALS, l'écran de sécurité fait un intval() sur chaque variable id_truc.
Donc c'est vraiment pas recommandé de montrer l'exemple de mettre autre chose qu'un entier dedans. Peut-être que ça passe quand même hein, mais même.
Je ne sais pas s'il vaut mieux corriger les fonctions du noyau dont tu parles, ou bien l'écran de sécurité. À priori plutôt les fonctions du noyau. Mais c'est une question pour spip-devel (ne continuer que sur devel ensuite).
--
RastaPopoulos