J’aimerais utiliser le plugin MACROSESSION mais il semble qu’il ne fonctionne qu’avec un utilisateur connecté (or j’ai besoin d’utiliser une variable de session pour un utilisateur lambda). Ou bien est-ce moi qui ne l’utilise pas convenablement ?
Ainsi le code
#SESSION_SET{variable, rouge}
#_SESSION : #_SESSION{variable}
#SESSION : #SESSION{variable}
retourne pour un utilisateur identifié
#_SESSION : rouge #SESSION : rouge
mais pour un utilisateur non identifié:
#_SESSION : #SESSION : rouge
Y a-t-il moyen de contourner ce problème ? Merci pour vos lumières !
J'aimerais utiliser le plugin MACROSESSION mais il semble qu'il ne fonctionne qu'avec un utilisateur connecté (or j'ai besoin d'utiliser une variable de session pour un utilisateur lambda). Ou bien est-ce moi qui ne l'utilise pas convenablement ?
Ainsi le code #SESSION_SET{variable, rouge}
\#_SESSION : #_SESSION{variable}
<br>
\#SESSION : #SESSION{variable}
retourne pour un utilisateur identifié #_SESSION : rouge #SESSION : rouge
mais pour un utilisateur non identifié: #_SESSION : #SESSION : rouge
Y a-t-il moyen de contourner ce problème ? Merci pour vos lumières !
C'est bien possible car je n'ai jamais considéré qu'on pouvait utiliser des
valeurs de session pour un visiteur non logé.
Ça revient à une variable globale pendant la durée du hit ?
Si hit veut dire durée de la session, oui, c'est ça. L'idéal, ce serait d'avoir une variable globale, pouvant prendre disons trois valeurs prédéfinies, et que chaque fichier inclus faisant appel à cette variable ait un cache séparé. Est-ce faisable ?
Le 04/01/2018 à 18:14, JLuc a écrit :
Le 04/01/2018 à 14:44, Romain a écrit :
J'aimerais utiliser le plugin MACROSESSION mais il semble qu'il ne fonctionne qu'avec un utilisateur connecté (or j'ai besoin d'utiliser une variable de session pour un utilisateur lambda). Ou bien est-ce moi qui ne l'utilise pas convenablement ?
C'est bien possible car je n'ai jamais considéré qu'on pouvait utiliser des
valeurs de session pour un visiteur non logé.
Ça revient à une variable globale pendant la durée du hit ?
Si hit veut dire durée de la session, oui, c'est ça. L'idéal, ce serait d'avoir une variable globale, pouvant prendre disons trois valeurs prédéfinies, et que chaque fichier inclus faisant appel à cette variable ait un cache séparé. Est-ce faisable ?
Je suis pas dans le code là et je ne me rend pas compte de ce que tu décris,
mais tu pourrais essayer en enlevant les 2 tests des lignes 46 et 47
Cad remplacer
if (!isset ($GLOBALS['visiteur_session'])
or !isset($GLOBALS['visiteur_session']['id_auteur'])
or !$GLOBALS['visiteur_session']['id_auteur'] )
par
if (!isset ($GLOBALS['visiteur_session']))
JLuc
Le 04/01/2018 à 18:14, JLuc a écrit :
Le 04/01/2018 à 14:44, Romain a écrit :
J'aimerais utiliser le plugin MACROSESSION mais il semble qu'il ne fonctionne qu'avec un utilisateur connecté (or j'ai besoin d'utiliser une variable de session pour un utilisateur lambda). Ou bien est-ce moi qui ne l'utilise pas convenablement ?
C'est bien possible car je n'ai jamais considéré qu'on pouvait utiliser des
valeurs de session pour un visiteur non logé.
Ça revient à une variable globale pendant la durée du hit ?
Si hit veut dire durée de la session, oui, c'est ça. L'idéal, ce serait d'avoir une variable globale, pouvant prendre disons trois valeurs prédéfinies, et que chaque fichier inclus faisant appel à cette variable ait un cache séparé. Est-ce faisable ?
Je suis pas dans le code là et je ne me rend pas compte de ce que tu décris
Néanmoins, si l'internaute n'est pas connecté,
sa session est normalement la même que celle de tous les internautes non connecté.
Donc à moins que tu ne souhaites effectivement que tous les non-connectés partagent ces valeurs de session,
je ne pense pas que ce que tu fais ait un sens (pour #SESSION comme pour #_SESSION).
Ton code a t il déjà été éprouvé quand plusieurs internautes non connectés visitent le site simultanément ?
JL
mais tu pourrais essayer en enlevant les 2 tests des lignes 46 et 47 Connexion · GitLab
Cad remplacer
if (!isset ($GLOBALS['visiteur_session'])
or !isset($GLOBALS['visiteur_session']['id_auteur'])
or !$GLOBALS['visiteur_session']['id_auteur'] )
par
if (!isset ($GLOBALS['visiteur_session']))
JLuc
Le 04/01/2018 à 18:14, JLuc a écrit :
Le 04/01/2018 à 14:44, Romain a écrit :
J'aimerais utiliser le plugin MACROSESSION mais il semble qu'il ne fonctionne qu'avec un utilisateur connecté (or j'ai besoin d'utiliser une variable de session pour un utilisateur lambda). Ou bien est-ce moi qui ne l'utilise pas convenablement ?
C'est bien possible car je n'ai jamais considéré qu'on pouvait utiliser des
valeurs de session pour un visiteur non logé.
Ça revient à une variable globale pendant la durée du hit ?
Néanmoins, si l'internaute n'est pas connecté,
sa session est normalement la même que celle de tous les internautes non connecté.
Donc à moins que tu ne souhaites effectivement que tous les non-connectés partagent ces valeurs de session,
je ne pense pas que ce que tu fais ait un sens (pour #SESSION comme pour #_SESSION).
Ton code a t il déjà été éprouvé quand plusieurs internautes non connectés visitent le site simultanément ?
Non, je suis en plein développement. Je vois ce que tu veux dire et si la session est la même pour tous les utilisateurs non identifiés, cela effectivement ne peut pas fonctionner (dommage car les deux lignes supprimées rendent bien #_SESSION fonctionnelle sur la session anonyme).
Ce que je souhaite, c'est que l'utilisateur puisse effectuer un choix, et que les pages présentées ensuite en tiennent compte. Je vais essayer de définir une variable dans une session php globale et la récupérer au départ de chaque squelette principal (rubrique, article,...), puis la passer en argument dans chaque squelette inclus. Je ne suis pas du certain que ça fonctionne, ni que ce soit pertinent...
Merci beaucoup en tout cas pour tes réponses !
Romain
JL
mais tu pourrais essayer en enlevant les 2 tests des lignes 46 et 47 Connexion · GitLab
Cad remplacer
if (!isset ($GLOBALS['visiteur_session'])
or !isset($GLOBALS['visiteur_session']['id_auteur'])
or !$GLOBALS['visiteur_session']['id_auteur'] )
par
if (!isset ($GLOBALS['visiteur_session']))
JLuc
Le 04/01/2018 à 18:14, JLuc a écrit :
Le 04/01/2018 à 14:44, Romain a écrit :
J'aimerais utiliser le plugin MACROSESSION mais il semble qu'il ne fonctionne qu'avec un utilisateur connecté (or j'ai besoin d'utiliser une variable de session pour un utilisateur lambda). Ou bien est-ce moi qui ne l'utilise pas convenablement ?
C'est bien possible car je n'ai jamais considéré qu'on pouvait utiliser des
valeurs de session pour un visiteur non logé.
Ça revient à une variable globale pendant la durée du hit ?
Ce que je souhaite, c'est que l'utilisateur puisse effectuer un choix, et que les pages présentées ensuite en tiennent compte. Je vais essayer de définir une variable dans une session php globale et la récupérer au départ de chaque squelette principal (rubrique, article,...), puis la passer en argument dans chaque squelette inclus. Je ne suis pas du certain que ça fonctionne, ni que ce soit pertinent...
Avec un cookie peut être ?
Ou avec la fonction spip auth_loger (qui loge un visiteur préalablement créé) ?
Ça m'intéresserait de savoir au final comment tu y seras parvenu.
JLuc
1°) Lorsque l'utilisateur fait son choix, je définis une variable globale $GLOBALS['etat'] le mémorisant. Il sera récupéré dans les noisettes par #EVAL{$GLOBALS['etat']}.
2°) Les fichiers sont mis en cache en fonction d'un contexte déterminé dans la fonction calculer_contexte_implicite() du fichier ecrire\public\assembler.php. J'ajoute donc simplement une petite ligne à cette fonction pour que $GLOBALS['etat']$ soit pris en compte et le tour est joué.
C'est pas joli joli de modifier le core, mais en attendant mieux... Il serait préférable de surcharger la fonction mais php ne le permet apparemment pas (je suis peu familier de ce langage). Parmi les variables de ce contexte, il y a la variable $GLOBALS['marqueur'], qui est visiblement faite pour ça. Il serait préférable de l'utiliser mais elle est abondamment utilisée par accès_restreint, et peut-être d'autres plugins, et je crains les interférences. A voir.
En tout cas sur le principe, ça a l'air de rouler. J'espère que je ne me fourvoie pas car je n'ai plus d'aspirine ! Et dans ce cas, ça vaut peut-être le coup de documenter sur spip-contrib, voire de réaliser un plugin.
Romain
Le 05/01/2018 à 01:11, Romain a écrit :
Le 04/01/2018 à 23:34, JLuc a écrit :
Ça m'intéresserait de savoir au final comment tu y seras parvenu.
JLuc
je vais peut être dire une bêtise, mais a priori, le plugin Panier gère déjà cette notion de cookie pour les personnes non logées.
Au clic, tu initialises le panier et tu peux ensuite récupérer l'id_panier créé et le lier à ce que tu veux.
Mais bon, pas testé
Peetdu
Le 05/01/2018 à 10:27, Romain a écrit :
Je crois que j'ai quelque chose de fonctionnel:
1°) Lorsque l'utilisateur fait son choix, je définis une variable
globale $GLOBALS['etat'] le mémorisant. Il sera récupéré dans les
noisettes par #EVAL{$GLOBALS['etat']}.
2°) Les fichiers sont mis en cache en fonction d'un contexte déterminé
dans la fonction calculer_contexte_implicite() du fichier
ecrire\public\assembler.php. J'ajoute donc simplement une petite ligne à
cette fonction pour que $GLOBALS['etat']$ soit pris en compte et le tour
est joué.
C'est pas joli joli de modifier le core, mais en attendant mieux... Il
serait préférable de surcharger la fonction mais php ne le permet
apparemment pas (je suis peu familier de ce langage). Parmi les
variables de ce contexte, il y a la variable $GLOBALS['marqueur'], qui
est visiblement faite pour ça. Il serait préférable de l'utiliser mais
elle est abondamment utilisée par accès_restreint, et peut-être d'autres
plugins, et je crains les interférences. A voir.
En tout cas sur le principe, ça a l'air de rouler. J'espère que je ne me
fourvoie pas car je n'ai plus d'aspirine ! Et dans ce cas, ça vaut
peut-être le coup de documenter sur spip-contrib, voire de réaliser un
plugin.
Romain
Le 05/01/2018 à 01:11, Romain a écrit :
Le 04/01/2018 à 23:34, JLuc a écrit :
Ça m'intéresserait de savoir au final comment tu y seras parvenu.
JLuc
Bonjour, et merci pour la suggestion. A priori mon problème est résolu (je touche du bois) mais l’examen du code de ce plugin devrait être très instructif.
1°) Lorsque l'utilisateur fait son choix, je définis une variable globale $GLOBALS['etat'] le mémorisant. Il sera récupéré dans les noisettes par #EVAL{$GLOBALS['etat']}.
2°) Les fichiers sont mis en cache en fonction d'un contexte déterminé dans la fonction calculer_contexte_implicite() du fichier ecrire\public\assembler.php. J'ajoute donc simplement une petite ligne à cette fonction pour que $GLOBALS['etat']$ soit pris en compte et le tour est joué.
C'est pas joli joli de modifier le core, mais en attendant mieux... Il serait préférable de surcharger la fonction mais php ne le permet apparemment pas (je suis peu familier de ce langage). Parmi les variables de ce contexte, il y a la variable $GLOBALS['marqueur'], qui est visiblement faite pour ça.
Effectivement c'est à cela que sert le marqueur.
Note qu'ainsi tu perds une bonne part du bénéfice du cache, puisque chaque internaute qui a interagit ne peut plus se servir que de ses propres caches.
Une manière plus fine serait peut être de ne personnaliser le contexte que pour les squelettes qui le nécessitent.
Il serait préférable de l'utiliser mais elle est abondamment utilisée par accès_restreint, et peut-être d'autres plugins, et je crains les interférences. A voir.
En tout cas sur le principe, ça a l'air de rouler. J'espère que je ne me fourvoie pas car je n'ai plus d'aspirine ! Et dans ce cas, ça vaut peut-être le coup de documenter sur spip-contrib, voire de réaliser un plugin.
Documenter est toujours utile mais je ne suis pas certain qu'il soit souhaitable de diffuser une contribution qui surcharge le core.
Note qu'ainsi tu perds une bonne part du bénéfice du cache, puisque chaque internaute qui a interagit ne peut plus se servir que de ses propres caches.
Je ne crois pas car la variable ajoutée ne peut prendre que trois valeurs. Il y aura donc au plus une multiplication par trois des caches. D'ailleurs je viens de vérifier en examinant l'évolution du cache en utilisant deux navigateurs différents (en étant non logué) sur lesquels je réalise les mêmes actions : après répétition sur le second navigateur d'une manœuvre exécutée sur le premier, le cache ne change pas (ni cache ni skel).
Une manière plus fine serait peut être de ne personnaliser le contexte que pour les squelettes qui le nécessitent.
Oui, mais j'ai essayé, mais je tombe sur un os. Si je ne définis pas $GLOBAL['etat']$ dans mes_options.php (ce qui va provoquer effectivement la multiplication de chaque cache, y compris ceux des squelettes qui ne dépendent pas de cette variable) mais seulement à l'appel des squelettes concernés, ça ne fonctionne pas. Le procédé de mise en cache reste quand même assez obscur pour moi. Il faudrait que j'examine le fonctionnement d'acces_restreint...
Documenter est toujours utile mais je ne suis pas certain qu'il soit souhaitable de diffuser une contribution qui surcharge le core.
Je n'y songe pas un instant. Je ne le ferai que si je trouve une solution qui me paraît propre (et le temps nécessaire...).
Merci pour tes observations, elles me sont très utiles.
Merci pour le tuyau-pipeline. Effectivement, cela semble être une piste judicieuse. Pour le moment je conserve mon bidouillage qui fonctionne, mais dès que je trouve un peu de temps, je mène l'enquête.
$GLOBALS['marqueur'] n'est pas forcément lié à une session, on peut l'utiliser pour d'autres cas, par exemple pour créer un cache différent en fonction de l'IP du visiteur (ce que j'avais fait pour un extranet).
Je ne sais pas si on pourrait utiliser le pipeline dans ce cas précis.
Bon, c'est une globale, c'est pas top (bonnes pratiques, tout ça), mais c'est pas pire que toutes les autres globales de SPIP
