Recherche avancée

Sur d’autres sites (9564)

• Roadmap #3844 : Gérer la parenté dans la déclaration d’un objet éditorial.

  12 mars 2018, par RastaPopoulos ♥

  J’ai continué dans la réflexion, ayant besoin de parent et enfants dans le plugin Duplicator. J’ai expliqué différents problèmes dans la liste Zone, mais pour pas le perdre, je vais copier ça dans ce ticket.

  Proposition de deux fonctions d’API génériques¶

  À mon avis il faut aller stable et plus abstrait que juste la déclaration dans l’objet, car
  1) ça peut éventuellement changer
  2) il faudrait pouvoir prendre en compte les cas courants magiquement même quand ya pas eu de déclaration explicite (id_rubrique, id_parent…)
  3) ça donne le parent d’un type d’objet pour remonter, mais ça ne donne pas l’inverse, les enfants

  Donc dans tous les cas il faudrait sûrement une fonction du genre
  array objet_info_parent($objet)
  dont l’algorithme serait :
  - s’il y a une déclaration explicite, c’est ça qu’on utilise
  - s’il y a un champ id_rubrique, on fait comme si ça avait été déclaré avec la rubrique array(type=>rubrique, champ=>id_rubrique)
  - s’il y a un champ id_parent, on considère que l’objet est arborescent de lui-même, et donc comme si ça avait été déclaré comme ça array(type=$objet, champ=>id_parent)

  Mais je pense aussi une fonction cette fois un peu plus longue, qui donnerait l’ensemble des enfants directs qu’on a réussi à trouver
  array objet_info_enfants($objet)
  dont l’algorithme serait :
  - un tableau de résultats en static pour toujours faire qu’une fois par hit
  - si $enfants[$objet] déjà rempli en renvoie
  - sinon on boucle sur tous les objets déclarés
  - pour chaque, si on trouve que l’objet peut avoir comme parent direct le $objet qu’on cherche, alors on l’ajoute à son tableau des enfants possibles
  - donc soit si dans sa clé "parent" ya $objet, soit s’il a un id_rubrique et qu’on cherchait pour "rubrique", soit s’il a un id_parent et qu’on cherchait pour son type

  Un parent direct dont l’objet n’est pas fixe¶

  Encore autre chose, je ne sais pas si c’est prévu, mais il faudrait pouvoir gérer les cas où le parent direct (on parle bien toujours de parentée directe, pas de liens multiples) peut être n’importe quel objet. Dans ce cas, il y a les champs objet et id_objet directement dans la table de l’objet.

  Un parent encore plus compliqué avec deux cas à tester pour le même contenu¶

  Mais il y a encore plus compliqué, et c’est le cas pour mes Chapitres, mais aussi le cas pour les Forums fournit par SPIP : le parent direct
  peut être
  - SOIT l’objet lui-même car il est arborescent avec un id_parent
  - SOIT n’importe quel autre contenu SI ET SEULEMENT SI le champ id_parent=0 !

  C’est bien le cas pour les forums :
  - le premier forum d’un fil a pour parent un objet SPIP, avec objet et id_objet remplis dans sa table ET id_parent=0
  - les sous-forums ont AUSSI gardé en mémoire objet et id_objet du forum racine, mais avec id_parent rempli avec l’identifiant id_forum de leur parent

  Dans ce cas on ne peut pas se baser uniquement sur le fait que objet et id_objet sont remplis. Le parent est un objet SPIP quelconque si objet et id_objet remplis ET id_parent=0. Et dès que id_parent>0 alors le parent direct est le même objet (forum, chapitre ou autre).

  Bref ya des cas comme ça qui sont plus complexes, mais pourtant légitimes, et en plus fournis dans la dist, maintenus par le core, donc il faut savoir les gérer aussi.

  Du coup pour conclure, j’ai pas forcément de solution directe pour la déclaration générique qui doit intégrer le noyau au final, mais c’est pour expliquer pourquoi peut-être, possiblement, il y aurait besoin d’un pipeline dédié dans Duplicator pour gérer ces enfantillages compliqués tant que dans l’API de parent c’est pas encore résolu.

  En tout cas ça fait avancer la réflexion :)

• 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 ?