pipelines, sessions et xray

Bonjour,
suite à la proposition de @JLuc dans Performances cache <INCLURE> VS #INCLURE - #17 par JLuc , j’ai installé Xray pour analyser le résultat d’une modif que je dois faire.
Je rencontre un problème, mais je ne sais pas si c’est un problème de plugin, de syntaxe, de logique ou de xray. Bref, j’ai besoin d’aide :sweat_smile:

J’aimerais pouvoir insérer une balise script dans ma section <head> de manière conditionnelle pour mes visiteurs (connectés ou pas), mais pas pour les auteurs ni les admins.
Comme mes rubriques incluent par défaut la balise #INSERT_HEAD, je me dis que ça peut être intéressant d’utiliser le pipeline qui va bien.

Donc dans mon pipeline php je fais:

function monplugin_insert_head($flux){
  $code = recuperer_fond('squelettes/monsquelette');
  return $flux.=$code;
}

Et dans mon squelette j’écris:

[(#SESSION{statut}|in_array{#LISTE{0minirezo,1comite}}|non)
  <script type="text/javascript" src="monscript.js"></script>
]

Jusque là, ça fonctionne correctement de ce que j’ai testé. J’ai bien mon script (ou pas) en fonction de si je teste avec un admin, un auteur ou un visiteur.

Mon vrai problème, c’est qu’en regardant ce qui se passe avec Xray et bien je vois:

ERREUR : Impossible de trouver le fichier squelette '/mon-super-article.html' dans les chemins SPIP pour 'monsite.local:443:62e2bcd5:cache:41aa020367a8c6d055eabf895cafe95c-/mon-super-article'.
Ça arrive pour certains squelettes de pages (accédés via ?page=). Le cache contient :

Array
(
    [info] => monsite.local:443:62e2bcd5:cache:41aa020367a8c6d055eabf895cafe95c-/mon-super-article
    [ttl] => 0
    [num_hits] => 3
    [mtime] => 1707297547
    [creation_time] => 1707297547
    [deletion_time] => 0
    [access_time] => 1707297552
    [ref_count] => 0
    [mem_size] => 384
)

Du coup, je ne sais pas si c’est moi qui est train de faire de la :poop: ou si c’est Xray qui se foire dans son analyse.
J’ai écrit la même chose en PHP:

<?php
  include_spip('inc/session');
  if(!in_array(session_get('statut'), ['0minirezo', '1comite'])){?>
  <script type="text/javascript" src="monscript.js"></script>
<? } ?>

et là le problème disparaît mais:

  • ça se transforme en inclusion dynamique (j’ai l’impression) car je n’ai plus de cache correspondant mais juste un squelette
  • c’est quand même un poil moins lisible que la version « tout spip ».

Bref, je suis preneur d’information sur ce qui se passe avec xray, et aussi de la meilleure manière spipienne de répondre à mon besoin.
Merci! :slight_smile:

À partir du moment où tu activeras la concaténation des scripts cela sera inutile et contre productif amha. Pourquoi veux-tu conditionner l’insertion de ton script en fait ?

Parce c’est un script d’analyse d’audience et que j’ai des problèmes dans mes données s’il est déclenché par des auteurs/admins.

edit: je viens de faire le test avec la minifcation activée, aucun problème particulier. J’ai bien le même JS minifié pour tout le monde, c’est juste que mes visiteurs ont une ressource en plus à télécharger (mon script maison) au final.

Amha, dans ce cas le plus simple est de coller l’appel de ton script et son test directement dans le head des squelettes concernés. Et bien sûr d’utiliser du php pour le test car c’est un des rares cas où on recommande ça cf Du php dans le squelette à la place de #SESSION ou #CACHE 0 - SPIP-Contrib

Mais qu’est ce que tu demandes à voir précisément à ce moment ?

Je n’ai jamais rencontré cette erreur. Elle ne signale pas un problème dans ton code, mais que XRay n’arrive pas à gérer cette situation, probablement car c’est lié à un squelette de page et non d’inclusion.

Quelques remarques :

  • XRay est un outil de débuging; à utiliser le temps de la mise au point seulement
  • Je l’utilise sur des squelettes d’inclusion mais rarement sur des squelettes de page (avec zcore ils sont pas très intéressants…)
    Or, le modele d’url et les fonctions de codage décodage de spip s’interposent entre le nom de la page, le nom du squelette de la page et les noms de ses caches. Je n’ai pas creusé, et XRay n’a qu’une gestion basique du nommage des caches de page. Il y a aussi une possibilité (peu testée) de définir une fonction xray_reconnaitre_si_cache_est_page si tu en sais plus sur ton modèle d’url propres et ses rapports avec les caches.

Donc

  • Si tu peux, déporte le mécanisme à étudier dans une inclusion. La recherche Xray y sera pleinement opérationnelle.
  • Sinon, si tu veux étudier des squelettes de pages, n’utilise pas les réécritures d’url le temps que tu te sers de XRay.

Merci JLuc.

Ce que je demande à voir, c’est vérifier que je génère bien 2 caches: 1 pour mes utilisateurs connectés (0minirezo et 1comite) et un pour les autres. Et comme tu suggérais d’utiliser Xray pour ceux qui veulent en savoir un peu plus j’ai saisi l’opportunité. J’avoue que l’interface est un chouilla plus lisible que mes grep -r "mon-pattern" tmp/cache/calcul que je faisais avant.

J’ai bien saisi que Xray est pour le debug, je ne compte pas le mettre en prod rassures toi. En revanche, par rapport au code que j’ai mis plus haut tu ferais quelles modifications pour une inclusion dans un plugin? Je ne suis pas très sûr de te suivre. Il faudrait que dans mon repertoire squelettes du plugin je fasse un <INCLURE> d’une noisette?

@b_b c’est justement ce que je veux éviter. Ce n’est pas moi qui ait codé le site, je n’ai pas prévu de temps pour faire un peu de refactor donc ça veut dire 48 nouvelles inclusions dans autant de fichiers. Alors qu’il y a une balise INSERT_HEAD faite exprès pour faire ça (et qui se trouve déjà dans mes 48 fichiers). Pourquoi ne pas se simplifier la vie?
Et sinon pour SESSION, je pense que je suis dans le cas où je peux l’utiliser. Car j’utilise #SESSION{statut} et j’ai exactement le nombre de cache auquel je m’attendais. Mais c’est bien parce que je ne m’occupe que du statut…

Merci pour vos retours! :slight_smile:

Attention il faudrait tester avec plusieurs différents visiteurs logés, car en utilisant #SESSION a priori ça sera plutôt « 1 cache pour chaque utilisateur connecté plus 1 cache pour les anonymes » (ça sessionne même si toi tu ne t’occupes que du statut).
Tu peux aussi mettre un marqueur genre <!-- icijesuisici --> dans ton squelette et interroger xray pour qu’il te liste les caches contenant icijesuisici (avec l’option de recherche dans tout le contenu)

yep c’est ce que je fais! :wink:

Tu peux mettre une balise #DATE dans ton squelette, et vérifier à l’affichage dans les deux cas de figures qu’elle est différente et ne change pas, avec plusieurs visites connecté / non connecté depuis plusieurs navigateurs, en doublant en navigation privée.
Je précise : #DATE en dehors de toute boucle, pour que ce soit bien la date courante au moment du calcul, et pas le champ date d’un objet (et en vérifiant qu’elle ne soit pas passée dans l’#ENV)

Avec le plugin macrosession (a priori compatible spip 4.2) ça s’écrit plus lisiblement :
[EDIT]

#_AUTORISER_SI{monscript}
<script type="text/javascript" src="monscript.js"></script>
#_AUTORISER_FIN

en définissant la fonction autoriser_monscript_dist dans ton fichier d’autorisations.

Hello, je rétropédale sur ce que j’ai dit précémment, et notamment dans ma réponse à b_b ici: pipelines, sessions et xray - #6 par cpol0

Je me suis fait avoir dans mes tests parce que j’utilise le plugin accès restreint qui me génère un cache différent entre mes visiteurs connectés et mes non connectés (les connectés ont accès à une zone spéciale). Du coup ce n’était pas ma balise SESSION qui différenciait le code appelé, mais le path du cache en lui même… En faisant des tests plus poussés avec des utilisateurs ayant les mêmes zones, l’utilisation de #SESSION dans le pipeline ne fonctionne pas, ça revient à faire une inclusion statique.

Du coup je suis repassé sur la solution que je voulais pas (des inclures partout dans tous mes squelettes), et là j’ai bien observé que oui, #SESSION{statut} me génère bien un cache par utilisateur connecté… Donc j’ai fait en PHP pour contourner le problème comme suggéré.

Bref, au final:

  • oui SESSION faut faire gaffe
  • si vous avez accès restreint, ne pas oublier que chaque config de zone possède son propre cache
  • je ne sais pas pour le reste des pipeline, mais insert_head faut le considérer comme un #INCLURE et pas <INCLURE>