Recherche avancée

Sur d’autres sites (5143)

• Anomalie #3823 : Pagination et connect

  10 février 2017

  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></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></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
  

  $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…

• Anomalie #4245 (Fermé) : Petit bug de sous_repertoire()

  11 décembre 2018

  Découvert hier, un enchaînement tueur :

  <span class="CodeRay"><span class="local-variable">$demo</span> = sous_repertoire(_DIR_TMP, <span class="string"><span class="delimiter">'</span><span class="content">demo_</span><span class="delimiter">'</span></span>);
  <span class="comment">// $demo = 'tmp/demo_'</span>
  <span class="local-variable">$bug</span> = sous_repertoire(<span class="local-variable">$demo</span>, <span class="string"><span class="delimiter">'</span><span class="content">potiron</span><span class="delimiter">'</span></span>);
  </span>
  Télécharger

  Le système a rencontré une erreur lors de l’écriture du fichier tmp/demo/potiron/.plat.

  En fait, lors de l’appel de sous_repertoire($base, $subdir), la fonction vire les / et _ finaux de $base (mais pas le _ final éventuel de $subdir).
  Il se retrouve ici à vouloir créer le répertoire tmp/demo/potiron au lieu de tmp/demo_/potiron et n’y arrive pas, vu que le répertoire parent (demo) n’existe pas.

  Histoire¶

  Après quelques fouilles archéologiques, il se trouve que le problème survient probablement avec r8196 qui refactore différemment le code de r6395 :
  - 6395 fil@rezo.n     if (!preg_match(',[/_]$,', $base)) $base .= '/';
  - 8196 esj@rezo.n     if (preg_match(',[/_]$,', $base)) $base = substr($base,0,-1);
  - 16035 fil@rezo.n     $base = rtrim($base, '/_');

  Le tout devait être, je suppose, pour prendre en compte les excentriques répertoires "plats" (dépendants maintenant de la présence de la constante _CREER_DIR_PLAT).

  Corrections¶

  Plusieurs corrections possibles :
  - A) virer la constante _CREER_DIR_PLAT et ses actions, et le rtrim de ce souligné (on est en 2018…).
  - B) simplement appliquer le rtrim du souligné si _CREER_DIR_PLAT est présent (ça corrige pas le bug que $subdir n’aurait alors pas ce rtrim non plus !)
  - C) B + corriger le rtrim pour $subdir de la même manière.

  Je suis partisan de A) sur le trunk, et B) ou C) sur 3.2 et 3.1.

  Des avis ?

• Anomalie #3799 : appliquer_filtre ne s’applique pas aux filtres image_

  10 février 2017

  L’intention que tu cites n’était peut être pas forcément le but de la fonction appliquer_filtre() à l’origine.

  Bon, j’ai un problème. Comme je disais en #note-7 il y a un bug sur appliquer filtre et l’option qui avait été ajoutée en r71781.

  En plein dans le bug¶

  Il y a un cas intéressant sur la zone dans SarkaSPIP, parmi d’autres :

  [(#ENVid_rubrique|appliquer_filtreaccesrestreint_rubrique_restreinte,0|oui) #SETretour_logout, #URL_PAGEsommaire]
  function accesrestreint_rubrique_restreinte($id_rubrique, $id_auteur = null) 
  
  

  Le zéro passé en second paramètre, on ne sait pas s’il était
  - à destination de appliquer_filtre() pour éviter absolument qu’il retourne la valeur id_rubrique SI accès restreint est absent, ou s’il était
  - à destination de accesrestreint_rubrique_restreinte() pour indiquer l’auteur 0 (ce qui est peu probable)
  Et du coup, ça casse le fonctionnement de accesrestreint_rubrique_restreinte() car ça ne prend pas en compte le visiteur courant car $id_auteur ne vaut plus null

  À d’autres endroits au contraire, par exemple dans Emballe Medias, on trouve :
  

  [(#INCLUREjavascript/jquery.shiftcheckbox.js|appliquer_filtreminifier,js)]
  

  Ici, la présence de l’option ’js’ fait que appliquer_filtre va comprendre qu’il doit toujours retourner le contenu d’origine même en absence du filtre.
  C’est d’ailleurs très certainement ce qui est souhaité ici. Sauf que ce n’est pas voulu explicitement a priori.

  On trouve aussi un usage avec |sinon :
  

  ["geometry" : (#GEOMETRY|appliquer_filtrewkt_to_json|sinon"type" : "Point", "coordinates" : [#LON, #LAT]),]
  

  Corrections de appliquer_filtre en créant une seconde fonction ?¶

  Ces 2 derniers exemples montrent que quelque soit l’option choisie pour corriger on va casser des usages (en créant une seconde fonction pour faire l’inverse), ie :

  Option Historique)
  - T|appliquer_filtre{F} retourne ’’ si F introuvable
  - T|appliquer_filtre_ou_continuer retourne T si F introuvable

  Option Chaînage)
  - T|appliquer_filtre{F} retourne T si F introuvable
  - T|appliquer_filtre_sinon_rien{F} retourne ’’ si F introuvable

  Ou déprécier appliquer_filtre()¶

  Une autre solution est de créer 2 nouvelles fonctions pour remplacer appliquer_filtre et son fonctionnement incertain.
  Contrainte : elles ne doivent pas commencer par filtre_.
  - T|utiliser_filtre{F} retourne T si F introuvable (chaînage)
  - T|utiliser_filtre_sinon_rien{F} retourne ’’ si F introuvable

  C’est peut être une solution acceptable. On aurait du être plus vigilent en introduisant une nouvelle fonction plutôt qu’un paramètre en plus à appliquer_filtre() alors que celle ci utilise func_get_args…