Evolution #3899
Comportement des inclusions avec le paramètre connect.
0%
Description
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 :
<INCLURE{fond=test, connect=truc} /> #INCLURE{fond=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>
.
- 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> 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 ?
Related issues
History
#1
Updated by marcimat 🌻 about 4 years ago
- Related to Anomalie #3823: Pagination et connect added
#2
Updated by b b about 4 years ago
Merci pour cette analyse détaillé :)
Perso, je penche plus pour ta dernière proposition pour sa simplicité et le résultat fonctionnel obtenu.
#3
Updated by marcimat 🌻 about 4 years ago
https://core.spip.net/projects/spip/repository/revisions/14024 pour info sur l'origine de ce code.
#4
Updated by marcimat 🌻 about 4 years ago
- Status changed from Nouveau to Fermé
- Resolution set to fixed
Appliqué en 3.2 par https://core.spip.net/projects/spip/repository/revisions/23411
#5
Updated by b b about 4 years ago
Bien joué, grande classe :)