[spip-dev] filtre |form_hidden et urls de type html

b_b · Août 27, 2009, 4:35

Bonjour,

Je ne suis pas certain que ça vienne de là mais le commit 13939 (
http://trac.rezo.net/trac/spip/changeset/13939 ) semble poser problème
dans certains cas. Voici la config du SPIP qui pose problème :

SPIP 2.0.9 SVN [14430] avec urls html activées
plugins installés : calendriermini(0.3), cfg(1.14.0),
noisette_delicious(1.0), nospam(0.4), nuage(1.4), openid(0.8.8)
,saisies(1.2), spip_bonux(1.8.1), spipclear(0.2), opensearch(0.1)

J'ai dans le code du formulaire de recherche de ce blog des champs
hidden étranges. Ceux-ci disparaissent au recalcul de la page. Par
exemple voici ce que ça donne à l'instant :

Ce qui fait qu'une recherche sur le site renvoie vers l'url suivante :

http://www.weblog.eliaz.fr/rubrique1.html?page=rubrique&id_rubrique=1&archives=2006-12-19&date=2009-08-27+01%3A37%3A48&date_default=1&date_redac=2009-08-27+01%3A37%3A48&date_redac_default=1&recherche=webmestre

J'ai remarqué l'erreur en effectuant une recherche sur mon blog il y a
deux jours. La recherche m'a renvoyé sur une page dont l'url contenait
un paramètre id_article=xx (erreur due à la présence d'un champ hidden
id_article dans le formulaire de recherche).

Pour info dans SpipClear le formulaire de recherche est appelé de cette façon :

#FORMULAIRE_RECHERCHE{(#ID_SECTEUR|generer_url_entite{rubrique})}

J'ai vérifié sur un autre blog utilisant SpipClear avec des urls
propres2 et le bug ne se présente pas.

esj · Août 29, 2009, 10:02

Je ne reproduis pas en SPIP 2.1 [14432].
Il faudrait regarder les plugins, d'autant que le 2e argument des balises dynamiques a changé:
http://trac.rezo.net/trac/spip/changeset/14430

Committo,Ergo:Sum

b_b · Août 31, 2009, 11:18

Bonjour Emmanuel,

Bon j'ai avancé dans la recherche des causes de ce problème. C'est
cette écriture qui est la fautive (avec ou sans urls propres) testée
sur un SPIP 2.1.0 dev SVN [14439] :

#FORMULAIRE_RECHERCHE{(#ID_SECTEUR|generer_url_entite{rubrique})}

On utilise ça dans SpipClear pour restreindre la recherche au secteur
correspondant au blog spipclear. Un appel du formulaire de recherche
avec la syntaxe ci-dessus génère les champs hidden suivant dans le
formulaire sur une page article :

Alors qu'un appel du formulaire de recherche avec
#FORMULAIRE_RECHERCHE donne un seul champ hidden sur la même page
article :

Après d'autres recherche j'ai trouvé que le commit 13939 sur le filtre

form_hidden est responsable de ces erreurs (le problème disparait en

13938). Le filtre semble récupérer un peu "trop" d'éléments dans le
contexte depuis ce commit.

esj · Août 31, 2009, 11:43

Bonjour Bruno

#FORMULAIRE_RECHERCHE{(#ID_SECTEUR|generer_url_entite{rubrique})}

On utilise ça dans SpipClear pour restreindre la recherche au secteur
correspondant au blog spipclear. Un appel du formulaire de recherche
avec la syntaxe ci-dessus génère les champs hidden suivant dans le
formulaire sur une page article :

<input name="article19" value="" type="hidden" />
<input name="id_article" value="19" type="hidden" />
<input name="id_rubrique" value="4" type="hidden" />
<input name="page" value="rubrique" type="hidden" />

Alors qu'un appel du formulaire de recherche avec
#FORMULAIRE_RECHERCHE donne un seul champ hidden sur la même page
article :

<input name="page" value="recherche" type="hidden" />

Après d'autres recherche j'ai trouvé que le commit 13939 sur le filtre
>form_hidden est responsable de ces erreurs (le problème disparait en
13938). Le filtre semble récupérer un peu "trop" d'éléments dans le
contexte depuis ce commit.

Le pb est que limiter les hidden à seulement "page" crée un bug dans d'autres système d'URL
(les "html" si je me souviens bien), c'était la raison de 13939.
Le filtre form_hidden distingue bien ce qui est donné par son argument (qui est prioritaire)
et ce qui vient du contexte de l'URL. Comment l'utilises-tu exactement ? Normalement le id_rubrique
que tu fournis devrait être prioritaire sur celui déduit de l'URL courante.

Committo,Ergo:Sum

b_b · Août 31, 2009, 9:09

Bonsoir Emmanuel,

Bonjour Bruno

#FORMULAIRE_RECHERCHE{(#ID_SECTEUR|generer_url_entite{rubrique})}

On utilise ça dans SpipClear pour restreindre la recherche au secteur
correspondant au blog spipclear. Un appel du formulaire de recherche
avec la syntaxe ci-dessus génère les champs hidden suivant dans le
formulaire sur une page article :

<input name="article19" value="" type="hidden" />
<input name="id_article" value="19" type="hidden" />
<input name="id_rubrique" value="4" type="hidden" />
<input name="page" value="rubrique" type="hidden" />

Alors qu'un appel du formulaire de recherche avec
#FORMULAIRE_RECHERCHE donne un seul champ hidden sur la même page
article :

<input name="page" value="recherche" type="hidden" />

Après d'autres recherche j'ai trouvé que le commit 13939 sur le filtre
>form_hidden est responsable de ces erreurs (le problème disparait en
13938). Le filtre semble récupérer un peu "trop" d'éléments dans le
contexte depuis ce commit.

Le pb est que limiter les hidden à seulement "page" crée un bug dans
d'autres système d'URL
(les "html" si je me souviens bien), c'était la raison de 13939.
Le filtre form_hidden distingue bien ce qui est donné par son argument (qui
est prioritaire)
et ce qui vient du contexte de l'URL. Comment l'utilises-tu exactement ?

Voici la configuration utilisée pour le test : un SPIP 2.1.0 dev SVN
[14440] avec une copie de squelettes-dist/article.html dans laquelle
je remplace #FORMULAIRE_RECHERCHE par
#FORMULAIRE_RECHERCHE{(#ID_SECTEUR|generer_url_entite{rubrique})} .

Normalement le id_rubrique
que tu fournis devrait être prioritaire sur celui déduit de l'URL courante.

Le problème n'est pas trop l'id_rubrique généré par form_hidden mais
plutôt l'id_article. En effet celui-ci fait que le formulaire de
recherche redirige sur cette url si la recherche est lancée depuis la
page spip.php?article19 :

spip.php?article19=&id_article=19&id_rubrique=4&page=rubrique&recherche=test

Dans le cas de spipclear, qui est basé sur un squelette à squelette
unique, cela à pour conséquence qu'on affiche l'article 19 sous les
résultats de la recherche.

esj · Août 31, 2009, 9:55

Voici la configuration utilisée pour le test : un SPIP 2.1.0 dev SVN
[14440] avec une copie de squelettes-dist/article.html dans laquelle
je remplace #FORMULAIRE_RECHERCHE

Ah, le form_hidden incriminé est donc celui dans le squelette squelette-dist/formulaire/recherche.html standard
c'est ce dont je voulais m'assurer.

Le problème n'est pas trop l'id_rubrique généré par form_hidden mais
plutôt l'id_article. En effet celui-ci fait que le formulaire de
recherche redirige sur cette url si la recherche est lancée depuis la
page spip.php?article19 :

spip.php?article19=&id_article=19&id_rubrique=4&page=rubrique&recherche=test

Dans le cas de spipclear, qui est basé sur un squelette à squelette
unique, cela à pour conséquence qu'on affiche l'article 19 sous les
résultats de la recherche.

Hum, on est dans le cas où un truc marchait grâce à un bug:
le form_hidden a pour rôle de réinjecter tous les arguments,
il le faisait mal avant, ce qui arrangeait ce site à squelette unique
(pas tant que ça d'ailleurs, puisqu'il y a le squelette de recherche).

Surcharge le squelette de recherche par une copie où la ligne:
[(#ENV{action}|form_hidden)]
a disparu. Si j'ai bien compris ton site, ça devrait marcher.
Sinon, remplace cette ligne par:
[(#ENV{action}|parametre_url{id_article,''}|form_hidden)]

Committo,Ergo:Sum

cerdic · Septembre 1, 2009, 2:14

Voici la configuration utilisée pour le test : un SPIP 2.1.0 dev SVN
[14440] avec une copie de squelettes-dist/article.html dans laquelle
je remplace #FORMULAIRE_RECHERCHE

...

Surcharge le squelette de recherche par une copie où la ligne:
[(#ENV{action}|form_hidden)]
a disparu. Si j'ai bien compris ton site, ça devrait marcher.
Sinon, remplace cette ligne par:
[(#ENV{action}|parametre_url{id_article,''}|form_hidden)]

Dans

#FORMULAIRE_RECHERCHE{(#ID_SECTEUR|generer_url_entite{rubrique})}

#ENV{action} est censé être une url de rubrique, et il n'y a aucune chance que son form_hidden ne puisse générer un id_article, non ?
C'est ça le bug, si je comprends bien.

Cédric

esj · Septembre 1, 2009, 2:23

Bah non, #ENV{action} est l'URL de la page contenant ce formulaire, elle peut contenir n'importe quoi.

Committo,Ergo:Sum

cerdic · Septembre 1, 2009, 8:08

Bah non, encore heureux. #ENV{action} est l'url vers laquelle est postée la formulaire de recherche. En l'occurence l'url de la rubrique dans le cas ci-dessus.
form_hidden n'a aucune bonne raison de ressortir autre chose que ce que contient cette url.

Et en l'occurence, je confirme bien le bug dénoncé ici par b_b :
sur la page
http://localhost:8888/fraichsvn2/spip.php?article340&var_mode=calcul
form_hidden("spip.php?rubrique1")
renvoie bien
<input type="hidden" value="" name="article340"/>
<input type="hidden" value="fr" name="lang"/>
<input type="hidden" value="340" name="id_article"/>
<input type="hidden" value="1" name="id_rubrique"/>
<input type="hidden" value="rubrique" name="page"/>

ce qui est une aberration totale (seuls les 2 derniers hidden etant légitimes).

La faute vient de
http://trac.rezo.net/trac/spip/browser/spip/ecrire/urls/page.php#L60
qui reinjecte le contexte global dans l'url.

Je ne comprends pas trop pourquoi, et je laisse ceux qui ont trempé la dedans corriger sans casser encore les urls

Cédric

esj · Septembre 1, 2009, 8:52

la page
http://localhost:8888/fraichsvn2/spip.php?article340&var_mode=calcul
form_hidden("spip.php?rubrique1")
renvoie bien
<input type="hidden" value="" name="article340"/>
<input type="hidden" value="fr" name="lang"/>
<input type="hidden" value="340" name="id_article"/>
<input type="hidden" value="1" name="id_rubrique"/>
<input type="hidden" value="rubrique" name="page"/>

ce qui est une aberration

En effet, mais avant le depot 13939 qui pose pb à Bruno,
c'était pire car on pouvait se retrouver avec:
<input type="hidden" value="" name="article340"/>
sans même qu'il y ait:
<input type="hidden" value="340" name="id_article"/>
qui permettait au moins de s'y retrouver.

La faute vient de
http://trac.rezo.net/trac/spip/browser/spip/ecrire/urls/page.php#L60
qui reinjecte le contexte global dans l'url.

Je ne comprends pas trop pourquoi, et je laisse ceux qui ont trempé la dedans corriger sans casser encore les urls

Ca a été modifié par ce dépot:
http://trac.rezo.net/trac/spip/changeset/13939/spip/ecrire/urls/page.php
qui faisait suite à la discussion suivante il y a 4 mois:
http://comments.gmane.org/gmane.comp.web.spip.devel/53257
a propos d'un bug visible entre autres sur spipnet à l'époque.

Je maintiens donc que ces informations sont utiles, et qu'il n'y a pas lieu d'y revenir.
Il est normal que dans le cas d'un squelette très spécifique comme SpipClear,
on prenne ses précautions en virant ce qui peut induire en erreur dans le contexte.

Committo,Ergo:Sum

Bruno_Bergot · Septembre 1, 2009, 9:14

Bonsoir Emmanuel Et Cedric,

Committo,Ergo:sum a écrit :

la page
http://localhost:8888/fraichsvn2/spip.php?article340&var_mode=calcul
form_hidden("spip.php?rubrique1")
renvoie bien
<input type="hidden" value="" name="article340"/>
<input type="hidden" value="fr" name="lang"/>
<input type="hidden" value="340" name="id_article"/>
<input type="hidden" value="1" name="id_rubrique"/>
<input type="hidden" value="rubrique" name="page"/>

ce qui est une aberration

En effet, mais avant le depot 13939 qui pose pb à Bruno,
c'était pire car on pouvait se retrouver avec:
<input type="hidden" value="" name="article340"/>
sans même qu'il y ait:
<input type="hidden" value="340" name="id_article"/>
qui permettait au moins de s'y retrouver.

La faute vient de
http://trac.rezo.net/trac/spip/browser/spip/ecrire/urls/page.php#L60
qui reinjecte le contexte global dans l'url.

Je ne comprends pas trop pourquoi, et je laisse ceux qui ont trempé la dedans corriger sans casser encore les urls

Ca a été modifié par ce dépot:
http://trac.rezo.net/trac/spip/changeset/13939/spip/ecrire/urls/page.php
qui faisait suite à la discussion suivante il y a 4 mois:
http://comments.gmane.org/gmane.comp.web.spip.devel/53257
a propos d'un bug visible entre autres sur spipnet à l'époque.

Je maintiens donc que ces informations sont utiles, et qu'il n'y a pas lieu d'y revenir.
Il est normal que dans le cas d'un squelette très spécifique comme SpipClear,
on prenne ses précautions en virant ce qui peut induire en erreur dans le contexte.

Je vais tenter d'être le plus concis dans mes explications. Voilà le topo :

- j'appelle la page spip.php?article19 (article situé dans le secteur n° 4)

- le squelette article.html est celui de la dist avec pour simple modification un appel du formulaire de recherche avec :
[(#FORMULAIRE_RECHERCHE{[(#ID_SECTEUR|generer_url_entite{rubrique})]})]

Pour info j'ai aussi testé la syntaxe suivante qui donne les mêmes résultats : [(#INCLURE{fond=formulaires/recherche,action=#URL_RUBRIQUE{#ID_SECTEUR},recherche})]

Dans ce cas [(#ID_SECTEUR|generer_url_entite{rubrique})] renvoie : spip.php?rubrique4

J'ai bien un action="spip.php?rubrique4 " dans le formulaire généré par SPIP. Le problème est que j'ai aussi les champs hidden suivant dans le formulaire :

Et tout ce petit monde fait que si je lance une recherche avec le formulaire je suis redirigé sur une page dont voici l'url :

http://localhost/spip_svn/spip.php?article19=&id_article=19&date=2009-09-01+16%3A18%3A35&date_default=1&date_redac=2009-09-01+16%3A18%3A35&date_redac_default=1&id_rubrique=4&page=rubrique&recherche=test

Aucune trace de Spipclear dans tout ça...Donc si on maintient les choses en l'état qu'en est-il de la syntaxe que j'utilise :

[(#FORMULAIRE_RECHERCHE{[(#ID_SECTEUR|generer_url_entite{rubrique})]})]

Doit-on la considérer comme obsolète ?

cerdic · Septembre 1, 2009, 9:26

la page

http://localhost:8888/fraichsvn2/spip.php?article340&var_mode=calcul

form_hidden(« spip.php?rubrique1 »)

renvoie bien

ce qui est une aberration

En effet, mais avant le depot 13939 qui pose pb à Bruno,
c’était pire car on pouvait se retrouver avec:

sans même qu’il y ait:

qui permettait au moins de s’y retrouver.

Mais c’est un dialogue de sourd !

pas plus que

n’ont rien a faire dans le résultat de
form_hidden(« spip.php?rubrique1 »)

qui ne doit rien renvoyer d’autre que

form_hidden est un filtre qui est chargé de réinjecter en input hidden les arguments de la chaine de get de l’url presente dans

du formulaire. Ca n'a *rien* à voir avec l'url de la page courante.

La faute vient de

http://trac.rezo.net/trac/spip/browser/spip/ecrire/urls/page.php#L60

qui reinjecte le contexte global dans l’url.

Je ne comprends pas trop pourquoi, et je laisse ceux qui ont trempé la dedans corriger sans casser encore les urls

Ca a été modifié par ce dépot:
http://trac.rezo.net/trac/spip/changeset/13939/spip/ecrire/urls/page.php
qui faisait suite à la discussion suivante il y a 4 mois:
http://comments.gmane.org/gmane.comp.web.spip.devel/53257
a propos d’un bug visible entre autres sur spipnet à l’époque.

Je ne conteste pas le bug.
Mais ton correctif en a introduit un bien plus énorme.

Je maintiens donc que ces informations sont utiles, et qu’il n’y a pas lieu d’y revenir.

Non. Tu as changé le principe et le fonctionnement du filtre form_hidden en considérant qu’il ne pouvait implicitement s’appliquer que sur l’url de la page en cours.
C’est un usage particulier qui n’est pas du tout la généralité et qui casse complètement son principe.

Sur le fond, je suis même choqué que tu défende le fait que le résultat d’un filtre ne soit pas prédictible en fonction de ses données en entrée mais puisse changer en fonction de la page sur laquelle on le calcul.

C’est tordu psychologiquement, et complètement contraire à tout le fonctionnement de SPIP.

Cela veut même dire dans le cas particulier qui nous occupe que le formulaire de recherche présent en cache va changer en fonction de la dernière page sur laquelle il a été calculé (puisque le contexte du squelette ne change pas, mais son résultat change en fonction de l’url de la page dans laquelle il est appelé …)

De fait, en fonction de ce que l’on a en cache, on est même susceptible d’avoir des formulaires différents d’une fois sur l’autre sur une même page.

Il est normal que dans le cas d’un squelette très spécifique comme SpipClear,
on prenne ses précautions en virant ce qui peut induire en erreur dans le contexte.

Le problème n’a rien à voir avec spipclear mais uniquement avec le filtre form_hidden.
Cédric

esj · Septembre 1, 2009, 9:29

Je vais tenter d'être le plus concis dans mes explications. Voilà le topo :

...

[(#FORMULAIRE_RECHERCHE{[(#ID_SECTEUR|generer_url_entite{rubrique})]})]

Doit-on la considérer comme obsolète ?

J'ai l'impression que tu n'as pas vu passer mon message d'hier:

on est dans le cas où un truc marchait grâce à un bug:
le form_hidden a pour rôle de réinjecter tous les arguments,
il le faisait mal avant, ce qui arrangeait ce site à squelette unique
(pas tant que ça d'ailleurs, puisqu'il y a le squelette de recherche).

Surcharge le squelette de recherche par une copie où la ligne:
[(#ENV{action}|form_hidden)]
a disparu. Si j'ai bien compris ton site, ça devrait marcher.
Sinon, remplace cette ligne par:
[(#ENV{action}|parametre_url{id_article,''}|form_hidden)]

Est-ce que tu as essayé ? Car ce n'est pas ton argument de la balise FORMULAIRE_RECHERCHE qui est en cause,
c'est toujours valable d'écrire comme ça, c'est le fait que dans le cas précis de ton squelette général,
le form_hidden du squelette associé est inadapté car donnant trop d'info.

Committo,Ergo:Sum

cerdic · Septembre 1, 2009, 9:34

Je vais tenter d'être le plus concis dans mes explications. Voilà le topo :

...

[(#FORMULAIRE_RECHERCHE{[(#ID_SECTEUR|generer_url_entite{rubrique})]})]

Doit-on la considérer comme obsolète ?

J'ai l'impression que tu n'as pas vu passer mon message d'hier:

on est dans le cas où un truc marchait grâce à un bug:
le form_hidden a pour rôle de réinjecter tous les arguments,
il le faisait mal avant, ce qui arrangeait ce site à squelette unique
(pas tant que ça d'ailleurs, puisqu'il y a le squelette de recherche).

Surcharge le squelette de recherche par une copie où la ligne:
[(#ENV{action}|form_hidden)]
a disparu. Si j'ai bien compris ton site, ça devrait marcher.
Sinon, remplace cette ligne par:
[(#ENV{action}|parametre_url{id_article,''}|form_hidden)]

Est-ce que tu as essayé ?

Est-ce que tu as essayé de reproduire le bug simplement avec l'exemple de b_b ?
Tu aurais vu que ta proposition ne résoud rien, ce qu'on essaye d'expliquer dans tous les sens possibles

Car ce n'est pas ton argument de la balise FORMULAIRE_RECHERCHE qui est en cause,
c'est toujours valable d'écrire comme ça, c'est le fait que dans le cas précis de ton squelette général,
le form_hidden du squelette associé est inadapté car donnant trop d'info.

le form_hidden est buggué, oui

Cédric

esj · Septembre 1, 2009, 10:06

Il y a 4 mois j'ai corrigé un bug qui se révèle aujourd'hui poser un pb à un squelette spécifique.
Je propose une manière de résoudre le pb de ce squelette sans avoir à remettre encore en chantier les différents types d'URL qui ont connu bug sur bug. Ca me parait ce dont Bruno a besoin de manière urgente.

Maintenant, sur le fait que ma modif serait "complètement contraire à tout le fonctionnement de SPIP", il y a de quoi rigoler. Le nombre de fois dans le code de SPIP où on se permet de référencer le contexte sans crier gare est considérable.
Il y a pres de 100 appels de la fonction _request dans les fichiers du répertoire inc, qui comme son nom l'indique devraient pouvoir etre inclus sans référence à un contexte global.

Ce n'est pas une raison pour que je rajoute un cas ? Oui, bien sûr. Mais ça, ça s'appelle discuter de la sémantique de SPIP et convenir une bonne fois pour toutes de ce qu'on se permet et qu'on ne se permet pas. Cette discussion, elle est en filigrane depuis un bon moment, j'essaye de la faire vivre par tous les moyens (par exemple en réécrivant les squelettes avec #SET), mais tu l'interromps tout le temps. Tu crois vraiment que passer la soirée à parler d'un truc aussi pointu que le pb de Bruno est plus important ?

Je ne cherche pas à défendre un bout de code écrit il y a 4 mois, à unr époque où j'avais beaucoup à faire sur d'autres plans mais avais besoin de corriger ce bug. Sans doute y a-t-il mieux comme solution. En revanche, je défends le fait qu'il serait bon de consacrer le maximum de nos échanges à des pbs de fond.

Emmanuel

esj · Septembre 2, 2009, 8:04

Bon, avec [14444], il me semble que j'ai trouvé une solution à ton problème qui ne réintroduit pas celui sur lequel j'étais tombé lors de [13939]. Je reporte sur la 2.0 si tu confirmes.

Committo,Ergo:Sum

Bruno_Bergot · Septembre 2, 2009, 8:44

Bonjour Emmanuel,

[(#FORMULAIRE_RECHERCHE{[(#ID_SECTEUR|generer_url_entite{rubrique})]})]

Doit-on la considérer comme obsolète ?

Bon, avec [14444], il me semble que j'ai trouvé une solution à ton problème
qui ne réintroduit pas celui sur lequel j'étais tombé lors de [13939]. Je
reporte sur la 2.0 si tu confirmes.

Bien vu ce commit corrige le bug dont je parlais. Avec ma config de
test on a uniquement un champ hidden : <input type="hidden" value=""
name="rubrique4"/>.

Reste un autre petit bug (non issu de 13939) car avec les urls page le
formulaire de recherche renvoie sur spip.php?rubrique4=&recherche=test
(un = de trop dans l'url).

Par contre avec les urls html ça passe nickel on est bien renvoyé sur
: rubrique4.html?recherche=test

Merci encore ++

esj · Septembre 2, 2009, 10:53

Ce n'est pas que le "=" et le pb est aussi dans le input ci-dessus:
"rubrique4" n'est pas un paramètre d'URL mais est considéré comme tel
par le code des URL dites "page" et consorts.
Mais est-ce que ce "petit bug" est bloquant ?

Committo,Ergo:Sum

Bruno_Bergot · Septembre 2, 2009, 10:59

Toujours avec la configuration de test que je décrivais dans mes
messages précédents, oui cela est bloquant si on utilise les urls
"page". Car le formulaire redirige sur l'url :

spip.php?rubrique4=&recherche=test

Ce qui a pour effet d'afficher le squelette sommaire.html et non celui
de la rubrique 4.

Je vais tester avec les autres systèmes d'urls pour voir ce que ça donne.

Bruno_Bergot · Septembre 2, 2009, 11:22

Voici le résultat de mes tests avec les différents types d'urls :

prores : ok
propres2 : ok
html : ok
arbo : ok
propres_qs : pas bon
page : pas bon

Pour les urls propres_qs (dans le même style que pour les urls page),
on obtient un hidden <input type="hidden" value=""
name="-nom-de-la-rubrique-"/> qui fait que le formulaire redirige sur
urldusite.net/?nom-de-la-rubrique-=&recherche=test (donc affichage du
squelette sommaire au lieu de celui de la rubrique).