Comportement des inclusions avec le paramètre connect.
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 (closed). J'en fais un ticket dédié car c'est un problème distinct de ce qui est soulevé là bas.
Fonctionnement actuel
connect
Le paramètre d'URL 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 :
#INCLURE{fond=test, connect=truc}
Cette option d'inclusion est prise en compte dans recuperer_fond()
.
connect=truc
et paramètre d'url connect=bidule
Inclusion 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>
.
- Pour #INCLURE ça se passe dans balise_INCLURE_dist() là https://git.spip.net/spip/spip/src/branch/master/ecrire/public/balises.php#L1995
- Pour là ça se passe dans calculer_inclure() là https://git.spip.net/spip/spip/src/branch/master/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 ?