[spip-dev] #FORMULAIRE_RECHERCHE, form_hidden, et params en trop dans le GET

N'y a-t-il pas un problème avec #FORMULAIRE_RECHERCHE quand on veut
diriger vers une autre page que celle par défaut ?

On peut depuis longtemps passer une autre URL, sauf que dès que ce n'est
pas une page=truc, mais un objet SPIP avec son URL libre, ça ajoute
automatiquement des hidden qui aboutissent à des params en plus dans le
GET qui n'ont aucune raison d'être.

Si on fait #FORMULAIRE_RECHERCHE{#URL_RUBRIQUE} qui correspond à
#FORMULAIRE_RECHERCHE{trucmuche}, on veut alors arriver à :
domaine.com/trucmuche?recherche=prout

Sauf qu'on arrive à :
domaine.com/trucmuche?id_rubrique=123&page=rubrique&recherche=prout

HORREUR.

C'est |form_hidden qui fait ça, en étant couplé au fait que ça part en
GET. Quand c'est en POST, ça ne se voit pas mais là pour la recherche on
veut bien évidemment du GET, et personne ne veut ce résultat !

M'est-avis que c'est un bug, et c'est pas à chacun de trouver une
bidouille, mais à #FORMULAIRE_RECHERCHE de diriger vers une URL propre
comme ce que tout le monde attend. Mais comment faire ?

Travailler sur les tests unitaires de la fonction form_hidden qui font office de spec, et éplucher le comment du pourquoi on a fait ça dans les logs pour éviter de casser quelque chose ?

Note bien que
1/ c’est parfaitement fonctionnel, ce que tu demandes n’est pas un bugfix mais une amélioration, donc ça ne peut pas casser le fonctionnel d’un autre cas
2/ form_hidden est la pierre angulaire de tous les CVT, donc achtung
3/ on est quand même dans un cas borderline, et donc il est pas délirant que dans ce cas précis tu doives surcharger/modifier ton formulaire html pour avoir pile poil ce que tu veux

Une piste peut-être, mais je n’ai ouvert aucun fichier pour regarder : ajouter un argument optionnel pour squizzer le decodage de l’URL et ne reinjecter que les arguments explicites de l’URL fournie ?

Note bien que
1/ c’est parfaitement fonctionnel, ce que tu demandes n’est pas un bugfix mais une amélioration, donc ça ne peut pas casser le fonctionnel d’un autre cas
2/ form_hidden est la pierre angulaire de tous les CVT, donc achtung
3/ on est quand même dans un cas borderline, et donc il est pas délirant que dans ce cas précis tu doives surcharger/modifier ton formulaire html pour avoir pile poil ce que tu veux

Il y a quand même quelques problèmes et comportements qui vont pas à mon avis
donc c'est pas fonctionnel dans ces cas là

Cf form_hidden insère un hidden en trop (#3769) · Tickets · spip / spip · GitLab
Extraits : si la page courante est ?page=truc&id_truc=10, form_hidden insère toujours un hidden pour id_truc=10,
même si on l'applique à un argument comme #URL_PAGE{tagada} dans lequel aucun id_truc n'est mentionné.

Du coup si une page 'truc' s'occupe AUSSI d'autres choses qui n'ont pas de rapport,
ou des rapports plus complexes que "toujours tout sur un seul truc",
alors ce paramètre id_truc peut gravement perturber le fonctionnement.

C'est un cas assez général
et ça semble une autre conséquence problématique du comportement dénoncé par rastapopoulos.

Fil a commenté « Le code indique qu'on remplit d'abord d'après l'*action* puis on complète avec le contexte, sans doublonner. Il suffit donc normalement de préciser "id_truc=" dans l'action pour qu'il ne soit pas pris depuis le contexte. »

Mais euh... vraiment ?

JLuc