Sur d’autres sites (4594)

• Anomalie #3763 : Rendre cohérent et simplifier l’appel à sa propre page d’auteur

  2 avril 2016, par Franck Dalot

  b b a écrit :

  Si, il y a un peu doublon, mais comme le bug signalé avec concision ici est caché dans un texte "un peu" long, personne ne l’avait remarqué :p

  Du coup, #3534 n’aborde que le point signalé ici, on fermera un des deux. Et si ton ticket signale plusieurs bugs, tu dois pouvoir y virer la mention du bug signalé ici. Tu me suis ? ^^

  Non, je comprends pas du tout ce que tu veux dire b_b :-p
  A la limite tu fermes le mien, et tu fais une liaison avec, pour pas que cela se perde :-)

  En faite, je me fiche complètement de la solution qui serait faite. C’est le fait d’avoir deux pages qui sont pratiquement identique que je trouve dommage.
  Peut importe la page qui disparaitrait ! En faisant mon ticket j’avais dû être long pour faire comprendre le fait qu’il y avait aussi des différences au niveau des autorisations.

  Par contre je suis pas sûr que actuellement ce soit un bug, mais plutôt une évolution car cela touche l’ergonomie et serait sans doute mieux dans "Petites roadmap" avec les autres tickets qui concernerait l’espace privé avec comme cible spip 3.2 ou plus

• Anomalie #4414 (Nouveau) : get_magic_quotes_gpc obsolète en php 7.4

  14 décembre 2019, par Franck D

  Hello :)
  La fonction get_magic_quotes_gpc est obsolète en php 7.4 https://www.php.net/manual/fr/function.get-magic-quotes-gpc.php
  Spip contient :
  https://core.spip.net/projects/spip/repository/entry/spip/config/ecran_securite.php#L350
  https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/utils.php#L2913

  Il y en a aussi eu dans getid3 dans media, mais faudra sans doute attendre qu’il sorte une nouvelle version, par contre à voir si nous ne pouvons nous inspirer de sont patch :
  https://github.com/JamesHeinrich/getID3/commit/75454e8b19c7b1b041382b91906574fe484f605b
  https://github.com/JamesHeinrich/getID3/commit/1b836c57ec8f4f072068caae0cf9d843ee88d50b

  Franck

• Evolution #3899 (Nouveau) : Comportement des inclusions avec le paramètre connect.

  10 février 2017

  Il y a un comportement contre-intuitif dans un cas d’usage des inclusions et du paramètre connect, ce qu’à révélé une petite analyse dans #3823.
  J’en fais un ticket dédié car c’est un problème distinct de ce qui est soulevé là bas.

  Fonctionnement actuel¶

  Le paramètre d’URL connect¶

  Le paramètre connect=truc dans une URL d’un site SPIP permet d’indiquer à SPIP qu’il doit utilise le connecteur SQL ’truc’ dans les squelettes et les boucles utilisés,
  et donc utiliser config/truc.php en lieu et place de config/connect.php. À différents endroits du compilateur, ce paramètre est séparé du contexte d’environnement
  du squelette, notamment dans les boucles où il atterrit dans $boucles[$idb]->sql_serveur et sera utilisé pour les requêtes SQL générées.

  Inclusions en indiquant un connect spécifique¶

  Une autre manière d’indiquer que les squelettes / boucles utilisent un connecteur spécifique est de transmettre l’environnement connect=truc aux inclusions, de la sorte :
  

  #INCLUREfond=test, connect=truc
  

  Cette option d’inclusion est prise en compte dans recuperer_fond().

  Inclusion connect=truc et paramètre d’url connect=bidule¶

  Lorsqu’on a à la fois dans l’URL &connect=bidule, et une inclusion qui indique un connect spécifique tel que #INCLURE{fond=test, connect=truc}
  alors d’inclusion actuellement est chargée avec le paramètre d’URL, c’est à dire en utilisant connect=bidule.
  C’est cela qui est assez contre-intuitif et logiquement non désiré (le connect forcé ici devrait prendre le pas sur celui d’environnement).

  Comment améliorer ?¶

  Où cela se passe dans le code ?¶

  Ce qui se passe lorsqu’il y a cette écriture est, comme expliqué, 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 là ça se passe dans calculer_inclure() là https://core.spip.net/projects/spip/repository/entry/spip/ecrire/public/compiler.php#L169

  Solutions ?¶

  À ces 2 endroits, il faudrait du coup prendre en compte en priorité le $contexte['connect'] si existant

  • soit dans les 2 appels à la constante CODE_RECUPERER_FOND plutôt que d’écrire directement _request('connect'), mais c’est un peu compliqué car c’est du code compilé
  • soit directement dans recuperer_fond(), plus facile, inverser l’ordre :
    

        if (isset($contexte[’connect’])) 
            $connect = ($connect ? $connect : $contexte[’connect’]) ;
            unset($contexte[’connect’]) ;
        
    

    
    deviendrait :
    

        if (isset($contexte[’connect’])) 
            $connect = $contexte[’connect’] ;
            unset($contexte[’connect’]) ;
        
    

  Cette dernière correction serait la plus simple et la plus facile. Ça permettrait même d’annuler un connect superieur dans une inclusion
  en passant {connect=''}.

  Des avis ?