Sur d’autres sites (5940)

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

• Revision 99981 : Sur Opera 40 sous Windows 10, ça provoquait un « Uncaught ReferenceError : ...

  20 octobre 2016, par real3t@… — Log

  Sur Opera 40 sous Windows 10, ça provoquait un « Uncaught ReferenceError ? : tableau_sites is not defined » qui rendait les boutons calculer inutiles.

• Revision 99981 : Sur Opera 40 sous Windows 10, ça provoquait un « Uncaught ReferenceError : ...

  20 octobre 2016, par real3t@… — Log

  Sur Opera 40 sous Windows 10, ça provoquait un « Uncaught ReferenceError ? : tableau_sites is not defined » qui rendait les boutons calculer inutiles.