Pagination et connect #3823

Closed
opened 6 years ago by RealET · 9 comments
RealET commented 6 years ago

Bonjour,

Il me semble que je suis tombé sur un bug des pagination avec connect

Soit une page qui charge plusieurs fois le même INCLURE avec un connect différent à chaque fois :
<INCLURE{fond=inc_mini_plan,env,ajax,connect=connect1,p=1}>
<INCLURE{fond=inc_mini_plan,env,ajax,connect=connect2,p=2}>
<INCLURE{fond=inc_mini_plan,env,ajax,connect=connect3,p=3}>

Soit inc_mini_plan.html qui contient en substance :
#ANCRE_PAGINATION
<BOUCLE_Rubrique(spip_rubriques){id_parent=0}{par num titre}{pagination 5 #ENV{p}}>

  • #TITRE
  • #PAGINATION

    La pagination, au lieu de réutiliser le connect passé en argument utilise la connexion par défaut du site.

    Testé en 3.1.1 SVN 23133.

    Bonjour, Il me semble que je suis tombé sur un bug des pagination avec connect Soit une page qui charge plusieurs fois le même INCLURE avec un connect différent à chaque fois : <INCLURE{fond=inc_mini_plan,env,ajax,connect=connect1,p=1}> <INCLURE{fond=inc_mini_plan,env,ajax,connect=connect2,p=2}> <INCLURE{fond=inc_mini_plan,env,ajax,connect=connect3,p=3}> Soit inc_mini_plan.html qui contient en substance : #ANCRE_PAGINATION <BOUCLE_Rubrique(spip_rubriques){id_parent=0}{par num titre}{pagination 5 #ENV{p}}> <li>#TITRE</li> </BOUCLE_Rubrique> #PAGINATION La pagination, au lieu de réutiliser le connect passé en argument utilise la connexion par défaut du site. Testé en 3.1.1 SVN 23133.
    Poster

    Au passage, il n'y a pas de doc sur connect dans www.spip.net

    http://www.spip.net/fr_article5713.html en parle juste ici :

    la balise #INCLURE transmet l’éventuel paramètre connect présent dans l’URL, tout comme le fait déjà l’inclusion <INCLURE...>

    http://www.spip.net/fr_article5425.html parle de #CONNECT non documentée aussi

    Au passage, il n'y a pas de doc sur connect dans www.spip.net http://www.spip.net/fr_article5713.html en parle juste ici : > la balise #INCLURE transmet l’éventuel paramètre connect présent dans l’URL, tout comme le fait déjà l’inclusion <INCLURE...> http://www.spip.net/fr_article5425.html parle de #CONNECT non documentée aussi
    Owner

    Hum, c'est un peu casse gueule, car si ça ajoute &connect=truc dans l'URL (si pas d'ajax) en cliquant un lien de pagination, ça va passer tout le site en utilisant ce connect d'URL (hors ceux explicitement spécifiés)

    J'ai tenté d'ajouter éventuellement le $connect évuentuel à l'url de pagination (dans filtre_pagination_dist()), dans le tableau $pagination.
    Ça ajoute bien le connect sur les liens de pagination. Cependant à partir du moment où tu cliques dessus, ça n'a pas du tout le résultat attendu (au moins sans ajax) :
    le &connect=truc ajouté à l'URL est appliqué pour tous les <INCLURE ou #INCLURE même s'ils déclarent connect=autrechose. Pour ce point je sais pas si c'est un bug ou le comportement désiré…

    Hum, c'est un peu casse gueule, car si ça ajoute `&connect=truc` dans l'URL (si pas d'ajax) en cliquant un lien de pagination, ça va passer tout le site en utilisant ce connect d'URL (hors ceux explicitement spécifiés) J'ai tenté d'ajouter éventuellement le `$connect` évuentuel à l'url de pagination (dans `filtre_pagination_dist()`), dans le tableau `$pagination`. Ça ajoute bien le connect sur les liens de pagination. Cependant à partir du moment où tu cliques dessus, ça n'a pas du tout le résultat attendu (au moins sans ajax) : le `&connect=truc` ajouté à l'URL est appliqué pour tous les `<INCLURE` ou `#INCLURE` même s'ils déclarent `connect=autrechose`. Pour ce point je sais pas si c'est un bug ou le comportement désiré…
    b_b commented 6 years ago
    Owner

    Du coup, il suffirait peut-être de documenter le fait que ce cas d'usage n'est pas pris en charge ?

    Du coup, il suffirait peut-être de documenter le fait que ce cas d'usage n'est pas pris en charge ?
    Poster

    Euh, rajouter à la documentation une exception, c'est un peu comme les CAPTCHA : http://icp.ge.ch/sem/cms-spip/spip.php?article1853

    Au sujet des CAPTCHA, et en ce qui me concerne, le débat est clos depuis longtemps : c’est une réponse d’informaticien à un problème d’informaticien, au seul détriment des utilisateurs. Autrement dit parce que les développeurs versent dans la facilité et n’ont aucune envie de se compliquer la vie, ils reportent le problème et ses inconvénients sur les utilisateurs.

    Bref, il y a un problème de cohérence et documenter l'incohérence ne va pas la résoudre :(

    Euh, rajouter à la documentation une exception, c'est un peu comme les CAPTCHA : http://icp.ge.ch/sem/cms-spip/spip.php?article1853 >Au sujet des CAPTCHA, et en ce qui me concerne, le débat est clos depuis longtemps : *c’est une réponse d’informaticien à un problème d’informaticien, au seul détriment des utilisateurs. Autrement dit parce que les développeurs versent dans la facilité et n’ont aucune envie de se compliquer la vie, ils reportent le problème et ses inconvénients sur les utilisateurs.* Bref, il y a un problème de cohérence et documenter l'incohérence ne va pas la résoudre :(
    b_b commented 6 years ago
    Owner

    Merci beaucoup de nous signaler que les devs de SPIP "versent dans la facilité et n’ont aucune envie de se compliquer la vie", ça fait toujours plaisir...

    Merci beaucoup de nous signaler que les devs de SPIP "versent dans la facilité et n’ont aucune envie de se compliquer la vie", ça fait toujours plaisir...
    Owner

    La notion INCLURE{connect=x} avec &connect=y dans l'URL

    La documentation dans SPIP.net fait bien mention d'un connect dans l'URL. Dans transmise en tant qu'argument d'inclure.
    La seule documentation que je trouve qui propose cela est http://programmer.spip.net/Inclure-suivant-une-connexion (je sais pas qui a écrit ce truc).
    Ce qui se passe lorsqu'il y a cette écriture est, comme je le signalais, que le connect dans l'URL reste prioritaire sur celui de l'argument transmis à #INCLURE ou <INCLURE>.

    Déjà ce point pourrait être amélioré (mais ça touche du code pas si anodin)

    Le problème avec {pagination}

    Solution en suffixant les liens de pagination avec le connect.

    Dans tous les cas cette solution ne peut pas marcher, je ne vois pas l'intérêt de s'éterniser là dessus.

    Je le redis mais si :

    • la page du site utilise le connect '' par défaut (pas de connect=x dans l'URL)
    • il a un squelette normal, et dedans des boucles normales, et dedans à un endroit les inclusions avec connect et avec pagination que tu montres.
    • cliquer avec le comportement qui ajouterait &connect=xx dans l'url de pagination, va mettre &connect=xx dans l'URL du site
    • le site va alors s'afficher (tout le squelette) avec le connect=xx (même ta pagination cela dit ^^)

    Ce comportement là est contre-intuitif, faux et surtout non désiré.

    Autre solution ? ajax en cause.

    Le problème vient de l'ajax. Sans Ajax, le comportement de la pagination est correct.
    Du coup, je pense que le principal souci de ce côté vient que le rechargement 'ajax' ne tient pas compte du connect utilisé par le bloc rechargé.
    Donc ça se passe quelque part

    Remplacer

    $page['texte'] = encoder_contexte_ajax(array_merge($contexte, array('fond' => $f)), '', $page['texte'],
    				$options['ajax']);
    

    par (ajout du connect au contexte)

    $page['texte'] = encoder_contexte_ajax(
    	array_merge($contexte, array('fond' => $f, 'connect' => $connect)),
    	'', 
    	$page['texte'],
    	$options['ajax']
    );
    

    semble faire fonctionner l'ajax correctement.

    Je me demande s'il peut y avoir des effets de bord.

    Et sinon, merci `realet pour ton commentaire, mais tu es autant dev que nous. Et on est bien gentils de passer du temps sur des trucs dont on n'a pas besoin…

    ## La notion `INCLURE{connect=x}` avec &connect=y dans l'URL La documentation dans SPIP.net fait bien mention d'un connect dans l'URL. Dans transmise en tant qu'argument d'inclure. La seule documentation que je trouve qui propose cela est http://programmer.spip.net/Inclure-suivant-une-connexion (je sais pas qui a écrit ce truc). Ce qui se passe lorsqu'il y a cette écriture est, comme je le signalais, que le connect dans l'URL reste prioritaire sur celui de l'argument transmis à `#INCLURE` ou `<INCLURE>`. * Pour `#INCLURE` ça se passe dans `balise_INCLURE_dist()` là https://core.spip.net/projects/spip/repository/entry/spip/ecrire/public/balises.php#L1995 * Pour `<INCLURE>` là ça se passe dans `calculer_inclure()` là https://core.spip.net/projects/spip/repository/entry/spip/ecrire/public/compiler.php#L169 Déjà ce point pourrait être amélioré (mais ça touche du code pas si anodin) ## Le problème avec `{pagination}` ### Solution en suffixant les liens de pagination avec le connect. Dans tous les cas cette solution ne peut pas marcher, je ne vois pas l'intérêt de s'éterniser là dessus. Je le redis mais si : * la page du site utilise le connect '' par défaut (pas de connect=x dans l'URL) * il a un squelette normal, et dedans des boucles normales, et dedans à un endroit les inclusions avec connect et avec pagination que tu montres. * cliquer avec le comportement qui ajouterait `&connect=xx` dans l'url de pagination, va mettre `&connect=xx` dans l'URL du site * le site va alors s'afficher (tout le squelette) avec le `connect=xx` (même ta pagination cela dit ^^) Ce comportement là est contre-intuitif, faux et surtout non désiré. ### Autre solution ? ajax en cause. Le problème vient de l'ajax. Sans Ajax, le comportement de la pagination est correct. Du coup, je pense que le principal souci de ce côté vient que le rechargement 'ajax' ne tient pas compte du connect utilisé par le bloc rechargé. Donc ça se passe quelque part * dans `ajaxReload()` en JS https://core.spip.net/projects/spip/repository/entry/spip/prive/javascript/ajaxCallback.js#L625 qui n'aurait pas l'information connect, par exemple dans la clé 'data-ajax-env' * cette clé data-ajax-env est insérée par `encoder_contexte_ajax()` là https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/filtres.php * c'est `recuperer_fond()` qui semble appeler cette fonction en cas d'ajax là https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/utils.php#L3076 Remplacer <pre> $page['texte'] = encoder_contexte_ajax(array_merge($contexte, array('fond' => $f)), '', $page['texte'], $options['ajax']); </pre> par (ajout du connect au contexte) <pre> $page['texte'] = encoder_contexte_ajax( array_merge($contexte, array('fond' => $f, 'connect' => $connect)), '', $page['texte'], $options['ajax'] ); </pre> semble faire fonctionner l'ajax correctement. Je me demande s'il peut y avoir des effets de bord. Et sinon, merci `realet pour ton commentaire, mais tu es autant dev que nous. Et on est bien gentils de passer du temps sur des trucs dont on n'a pas besoin…
    Owner
    There is no content yet.
    Poster

    b_b, marcimat, je vous présente (ainsi qu'à tous les autres) mes excuses.

    Sans doute pas ma journée. Avec la crève.

    Et merci d'avoir cherché une solution.
    La piste du connect à passer au contexte d'Ajax me semble (vu d'ici) très pertinente !

    b_b, marcimat, je vous présente (ainsi qu'à tous les autres) mes excuses. Sans doute pas ma journée. Avec la crève. Et merci d'avoir cherché une solution. La piste du connect à passer au contexte d'Ajax me semble (vu d'ici) très pertinente !
    Owner

    Acceptées :)

    Appliqué en 3.2 par https://core.spip.net/projects/spip/repository/revisions/23411

    Version cible mise à 3.2
    Statut changé à Fermé

    Acceptées :) Appliqué en 3.2 par https://core.spip.net/projects/spip/repository/revisions/23411 **Version cible mise à 3.2** **Statut changé à Fermé**
    Sign in to join this conversation.
    No Milestone
    No project
    No Assignees
    3 Participants
    Notifications
    Due Date

    No due date set.

    Dependencies

    This issue currently doesn't have any dependencies.

    Loading…
    There is no content yet.