INCLUDE et cache

Bonjour,

Je galère depuis un moment avec un problème d’inclusion et de cache. Comme le forum spip ne semble plus très fréquenté, j’espère avoir de l’aide ici.

D’après certaines sources ( par exemple), il semble qu’un fichier inclus par INCLURE (et non #INCLURE) ait son propre fichier de cache. Aussi j’espère que <INCLURE{fond=fichier, variable=1}> va prendre en compte la valeur dynamique de la variable, c’est à dire que si je remplace variable=1 par variable=2, le cache utilisé ne sera pas le même. Or cela ne semble pas être le cas, cas la page obtenue reste identique jusqu’à ce qu’on force un nouveau calcul. J’aurais besoin d’un tel comportement en vue de servir des pages différentes en fonction d’une certaine variable de session. Y a-t-il un moyen de l’obtenir ?

Pour être très précis, dans , Matthieu Marcillaud propose cet exemple :

// fichier A.html
<INCLURE{fond=B}{type}{mot=triton} />
// fichier B.html
<INCLURE{fond=C}{env}{couleur=rouge} />
// fichier C.html
Type : #ENV{type} <br />
Mot : #ENV{mot} <br />
Couleur : #ENV{couleur}

En appelant spip.php?page=A&type=animal, on obtient bien :
``
Type : animal
Mot : triton
Couleur : rouge

Mais si maintenant on remplace triton par ornithorynque et rouge par bleu, la sortie reste la même jusqu’au recalcul (ce qui peut d’ailleurs être fait en changeant le paramètre type de l’URL ou même en ajoutant un paramètre bidon quelconque).

Merci pour votre aide éventuelle !

Le 06/07/2017 à 14:38, Erka a écrit :

Mais si maintenant on remplace triton par ornithorynque et rouge par bleu, la sortie reste la même jusqu'au recalcul (ce qui peut d'ailleurs être fait en changeant le paramètre type de l'URL ou même en ajoutant un paramètre bidon quelconque).

Je ne comprends pas ton problème. "triton" est en dur dans le squelette A… donc bah c'est justement le principe d'un cache de… rester en cache le temps qu'il est configuré (24h par défaut je crois). Donc où est le problème ?

En revanche si *l'environnement* change, là c'est dans un cache différent. Donc si "type" change dans l'URL, sans recalculer ça doit bien t'afficher autre chose.

--
RastaPopoulos

Merci pour ta réponse. J'ai pris cet exemple pour illustrer mais, bien évidemment, pour ce que je veux faire, la valeur ne sera pas en dur dans le code.

Mon utilisateur peut sélectionner deux modes, disons A et B. Je mémorise son choix à travers une variable de session par #SESSION_SET{mode, A} ou #SESSION_SET{mode, B}.

Ceci étant fait, je souhaite passer ce paramètre à un fichier inclu. Je procède en déclarant une variable d'environnement par #SET{mode, #SESSION{mode}}, puis

<INCLURE{fond=squel_inclu, mode=#GET{mode}}>

Et là, si l'utilisateur change de mode, ce n'est pas pris en compte tant qu'on ne force pas le calcul.

Le 06/07/2017 à 16:01, RastaPopoulos a écrit :

Le 06/07/2017 à 14:38, Erka a écrit :

Mais si maintenant on remplace triton par ornithorynque et rouge par bleu, la sortie reste la même jusqu'au recalcul (ce qui peut d'ailleurs être fait en changeant le paramètre type de l'URL ou même en ajoutant un paramètre bidon quelconque).

Je ne comprends pas ton problème. "triton" est en dur dans le squelette A… donc bah c'est justement le principe d'un cache de… rester en cache le temps qu'il est configuré (24h par défaut je crois). Donc où est le problème ?

En revanche si *l'environnement* change, là c'est dans un cache différent. Donc si "type" change dans l'URL, sans recalculer ça doit bien t'afficher autre chose.

J'ai une solution valable je crois.

Je crée un fichier toggle_mode.html qui bascule la variable de session mode de A vers B et réciproquement, auquel j'affecte un tempo de cache nul (j'indique le code plus bas, il n'est pas essentiel).

Puis un fichier main.html, qui est celui que spip appelle:
<INCLURE{fond=toggle_mode}>
<INCLURE{fond=skel_inclu.html, mode=#SESSION{mode}}>

Et un fichier skel_inclu ou je vérifie simplement que la bascule a bien eu lieu:
<p>Dans skel_inclu, mode est #ENV{mode}.</p>

Ça fonctionne et j'ai vérifié que main.html n'est pas recalculé à chaque fois (ce serait catastrophique) en ajoutant un mot dans ce fichier : il n'apparaît pas tant que je ne force pas le calcul, tandis que la bascule est bien effectuée. C'est donc bien un cache adéquat qui est appelé.

----------------
toggle_mode.html
---------------
#CACHE{0}
[(#SESSION{mode}|non) #SESSION_SET{mode, B}]
[(#SESSION{mode}|=={A}|oui)
   [(#SET{toggle, ' '})] [(#SESSION_SET{mode, B})]
]
[(#GET{toggle}|non) [(#SESSION_SET{mode, A})]]

Le 06/07/2017 à 16:14, Erka a écrit :

Merci pour ta réponse. J'ai pris cet exemple pour illustrer mais, bien évidemment, pour ce que je veux faire, la valeur ne sera pas en dur dans le code.

Mon utilisateur peut sélectionner deux modes, disons A et B. Je mémorise son choix à travers une variable de session par #SESSION_SET{mode, A} ou #SESSION_SET{mode, B}.

Ceci étant fait, je souhaite passer ce paramètre à un fichier inclu. Je procède en déclarant une variable d'environnement par #SET{mode, #SESSION{mode}}, puis

<INCLURE{fond=squel_inclu, mode=#GET{mode}}>

Et là, si l'utilisateur change de mode, ce n'est pas pris en compte tant qu'on ne force pas le calcul.

Le 06/07/2017 à 16:01, RastaPopoulos a écrit :

Le 06/07/2017 à 14:38, Erka a écrit :

Mais si maintenant on remplace triton par ornithorynque et rouge par bleu, la sortie reste la même jusqu'au recalcul (ce qui peut d'ailleurs être fait en changeant le paramètre type de l'URL ou même en ajoutant un paramètre bidon quelconque).

Je ne comprends pas ton problème. "triton" est en dur dans le squelette A… donc bah c'est justement le principe d'un cache de… rester en cache le temps qu'il est configuré (24h par défaut je crois). Donc où est le problème ?

En revanche si *l'environnement* change, là c'est dans un cache différent. Donc si "type" change dans l'URL, sans recalculer ça doit bien t'afficher autre chose.

_______________________________________________
liste spip
spip@rezo.net - désabonnement : envoyer un mail à spip-off@rezo.net

Archives : https://www.mail-archive.com/spip@rezo.net/maillist.html

Infos : http://listes.rezo.net/mailman/listinfo/spip

Documentation de SPIP : http://www.spip.net/

Irc : de l'aide à toute heure : http://spip.net/irc

Le 06/07/2017 à 17:56, Erka a écrit :

Ça fonctionne et j'ai vérifié que main.html n'est pas recalculé à chaque fois

Il y a deux caches, un cache PHP (squelettes => compilation => cache PHP) et un cache HTML (PHP => contenu de environnement/base de données => cache HTML).

#SESSION va te faire un fichier de cache différent pour chaque personne, puisque c'est avant compilation… Sauf pour quelques rares squelettes, ce n'est pas une très bonne pratique.

C'est justement les quelques rares seuls cas où on accepte d'utiliser du PHP dans les squelettes, avec <?php $GLOBALS['visiteur_session']['trucmuche'] … ?>

C'est un manque dans la doc il me semble d'ailleurs, je ne sais plus. (En gros 99% du temps il ne faut jamais jamais jamais de PHP dans les squelettes, mais pour tester des trucs propres à l'utilisateurice en cours, si.)

--
RastaPopoulos

Ok, je pense que je vois à peu près. Merci pour ton aide.

J'ai remplacé dans toggle_mode l'usage des #SESSION et #SESSION_SET par du php. Je constate que #CACHE{0} n'est plus indispensable.

Et plutôt qu'appeler #SESSION['mode'] pour récupérer le mode en cours, je crée une balise #MODE qui renvoie $GLOBALS['visiteur_session']['mode'].

C'est mieux ainsi ?

Le 06/07/2017 à 20:37, RastaPopoulos a écrit :

Le 06/07/2017 à 17:56, Erka a écrit :

Ça fonctionne et j'ai vérifié que main.html n'est pas recalculé à chaque fois

Il y a deux caches, un cache PHP (squelettes => compilation => cache PHP) et un cache HTML (PHP => contenu de environnement/base de données => cache HTML).

#SESSION va te faire un fichier de cache différent pour chaque personne, puisque c'est avant compilation… Sauf pour quelques rares squelettes, ce n'est pas une très bonne pratique.

C'est justement les quelques rares seuls cas où on accepte d'utiliser du PHP dans les squelettes, avec <?php $GLOBALS['visiteur_session']['trucmuche'] … ?>

C'est un manque dans la doc il me semble d'ailleurs, je ne sais plus. (En gros 99% du temps il ne faut jamais jamais jamais de PHP dans les squelettes, mais pour tester des trucs propres à l'utilisateurice en cours, si.)

Le 06/07/2017 à 22:03, Erka a écrit :

C'est mieux ainsi ?

Ah oui mais non en fait pour la récupération si c'est pour l'injecter dans une boucle ou inclure effectivement, t'es obligée de faire #SESSION… (et ça sert à rien de faire une balise pour ça, même ça va pas marcher puisque ça va garder en cache uniquement la dernière valeur et qu'en balise pour la session il FAUT que ça fasse un cache par personne pour ne pas avoir ça). Désolé la fatigue… :stuck_out_tongue:
Bonne soirée

--
RastaPopoulos

Le 06/07/2017 à 20:37, RastaPopoulos a écrit :

#SESSION va te faire un fichier de cache différent pour chaque personne, puisque c'est avant compilation… Sauf pour quelques rares squelettes, ce n'est pas une très bonne pratique.
C'est justement les quelques rares seuls cas où on accepte d'utiliser du PHP dans les squelettes, avec <?php $GLOBALS['visiteur_session']['trucmuche'] … ?>
C'est un manque dans la doc il me semble d'ailleurs, je ne sais plus. (En gros 99% du temps il ne faut jamais jamais jamais de PHP dans les squelettes, mais pour tester des trucs propres à l'utilisateurice en cours, si.)

C'est documenté là :

Et le plugin macrosession sert justement à gérer ces situations :

La page sur plugins.spip est à moitié à jour seulement :

(depuis fin juin les balises ne sont plus #_VISITEUR mais #_SESSION)

JLuc

Le 07/07/2017 à 17:18, JLuc a écrit :

Le 06/07/2017 à 20:37, RastaPopoulos a écrit :

#SESSION va te faire un fichier de cache différent pour chaque personne, puisque c'est avant compilation… Sauf pour quelques rares squelettes, ce n'est pas une très bonne pratique.
C'est justement les quelques rares seuls cas où on accepte d'utiliser du PHP dans les squelettes, avec <?php $GLOBALS['visiteur_session']['trucmuche'] … ?>
C'est un manque dans la doc il me semble d'ailleurs, je ne sais plus. (En gros 99% du temps il ne faut jamais jamais jamais de PHP dans les squelettes, mais pour tester des trucs propres à l'utilisateurice en cours, si.)

C'est documenté là :
Du php dans le squelette à la place de #SESSION ou #CACHE 0 - SPIP-Contrib

Et le plugin macrosession sert justement à gérer ces situations :
Plugin 'macrosession' : usage optimisé et extension des données de session - SPIP-Contrib

La page sur plugins.spip est à moitié à jour seulement :
Macros de session étendue - Plugins SPIP
(depuis fin juin les balises ne sont plus #_VISITEUR mais #_SESSION)

la doc sur plugins.spip devrait bientôt se mettre à jour.
JL

C'est documenté là :
Du php dans le squelette à la place de #SESSION ou #CACHE 0 - SPIP-Contrib

Et le plugin macrosession sert justement à gérer ces situations :
Plugin 'macrosession' : usage optimisé et extension des données de session - SPIP-Contrib

La page sur plugins.spip est à moitié à jour seulement :
Macros de session étendue - Plugins SPIP
(depuis fin juin les balises ne sont plus #_VISITEUR mais #_SESSION)

J'ai justement "découvert" ces deux articles aujourd'hui mais, vraiment, je suis à la peine. Je pensais avoir la solution mais finalement, quand mon truc à l'air de marcher, patatras, si je me déconnecte, ça ne fonctionne plus qu'à moitié. Je ne parviens absolument pas à démêler ce qui va partir en cache, quel type de cache, quand, pourquoi. Je teste des inclusions multiples à l'aveuglette. Tout ça pour utiliser une malheureuse variable de session. Il arrive même qu'ordonner à répétition un "recalcul" ne recalcule rien du tout. Caché c'est caché...

Je vais essayer de mettre en œuvre ce plugin, merci pour cette piste.

Erka.

JLuc

_______________________________________________
liste spip
spip@rezo.net - désabonnement : envoyer un mail à spip-off@rezo.net

Archives : https://www.mail-archive.com/spip@rezo.net/maillist.html

Infos : http://listes.rezo.net/mailman/listinfo/spip

Documentation de SPIP : http://www.spip.net/

Irc : de l'aide à toute heure : http://spip.net/irc

Fin de l'histoire (?).

Afin que mes mésaventures évitent éventuellement à d'autres personnes d'enrichir les fabricants d'aspirine, j'indique la manière dont je m'en suis sorti (je crois...). Plutôt qu'une variable de session, je trimbale simplement de page en page une variable d'environnement. Toute inclusion, tout appel de page, rubrique, etc, se fait en transmettant explicitement cette variable. Le pire est que j'avais cette solution en tête depuis le début mais, parce qu'elle me semblait lourde et inélégante, je m’obstinais à vouloir utiliser une variable de session. C'est finalement beaucoup plus léger, le cache me semble-t-il est mis en œuvre exactement comme il faut, et ça ne demande pas d'être particulièrement au fait de la manière dont il est géré par spip.

Erka

PS : mais j'essaierai quand même ce plugin qui me semble tout à fait pertinent quand j'aurai récupéré ! :wink:

Le 07/07/2017 à 22:57, Erka a écrit :

C'est documenté là :
Du php dans le squelette à la place de #SESSION ou #CACHE 0 - SPIP-Contrib

Et le plugin macrosession sert justement à gérer ces situations :
Plugin 'macrosession' : usage optimisé et extension des données de session - SPIP-Contrib

La page sur plugins.spip est à moitié à jour seulement :
Macros de session étendue - Plugins SPIP
(depuis fin juin les balises ne sont plus #_VISITEUR mais #_SESSION)

J'ai justement "découvert" ces deux articles aujourd'hui mais, vraiment, je suis à la peine. Je pensais avoir la solution mais finalement, quand mon truc à l'air de marcher, patatras, si je me déconnecte, ça ne fonctionne plus qu'à moitié. Je ne parviens absolument pas à démêler ce qui va partir en cache, quel type de cache, quand, pourquoi. Je teste des inclusions multiples à l'aveuglette. Tout ça pour utiliser une malheureuse variable de session. Il arrive même qu'ordonner à répétition un "recalcul" ne recalcule rien du tout. Caché c'est caché...

Je vais essayer de mettre en œuvre ce plugin, merci pour cette piste.

Erka.

JLuc

_______________________________________________
liste spip
spip@rezo.net - désabonnement : envoyer un mail à spip-off@rezo.net

Archives : https://www.mail-archive.com/spip@rezo.net/maillist.html

Infos : http://listes.rezo.net/mailman/listinfo/spip

Documentation de SPIP : http://www.spip.net/

Irc : de l'aide à toute heure : http://spip.net/irc

_______________________________________________
liste spip
spip@rezo.net - désabonnement : envoyer un mail à spip-off@rezo.net

Archives : https://www.mail-archive.com/spip@rezo.net/maillist.html

Infos : http://listes.rezo.net/mailman/listinfo/spip

Documentation de SPIP : http://www.spip.net/

Irc : de l'aide à toute heure : http://spip.net/irc

Je vais quand même avoir un souci, c'est que les liens produits par spip depuis le contenu éditorial ne vont pas connaître ce paramètre. Il faudrait que je surcharge les fonctions qui produisent ces liens afin d'ajouter systématiquement &mode=#ENV{mode}. Y a-t-il un moyen pas trop compliqué de faire ça ?

Erka

PS : si on trouve que je m'épanche un peu trop sur cette liste, ne pas hésiter à me le signifier...

Le 08/07/2017 à 07:58, Erka a écrit :

Fin de l'histoire (?).

Afin que mes mésaventures évitent éventuellement à d'autres personnes d'enrichir les fabricants d'aspirine, j'indique la manière dont je m'en suis sorti (je crois...). Plutôt qu'une variable de session, je trimbale simplement de page en page une variable d'environnement. Toute inclusion, tout appel de page, rubrique, etc, se fait en transmettant explicitement cette variable. Le pire est que j'avais cette solution en tête depuis le début mais, parce qu'elle me semblait lourde et inélégante, je m’obstinais à vouloir utiliser une variable de session. C'est finalement beaucoup plus léger, le cache me semble-t-il est mis en œuvre exactement comme il faut, et ça ne demande pas d'être particulièrement au fait de la manière dont il est géré par spip.

Erka

PS : mais j'essaierai quand même ce plugin qui me semble tout à fait pertinent quand j'aurai récupéré ! :wink:

Le 07/07/2017 à 22:57, Erka a écrit :

C'est documenté là :
Du php dans le squelette à la place de #SESSION ou #CACHE 0 - SPIP-Contrib

Et le plugin macrosession sert justement à gérer ces situations :
Plugin 'macrosession' : usage optimisé et extension des données de session - SPIP-Contrib

La page sur plugins.spip est à moitié à jour seulement :
Macros de session étendue - Plugins SPIP
(depuis fin juin les balises ne sont plus #_VISITEUR mais #_SESSION)

J'ai justement "découvert" ces deux articles aujourd'hui mais, vraiment, je suis à la peine. Je pensais avoir la solution mais finalement, quand mon truc à l'air de marcher, patatras, si je me déconnecte, ça ne fonctionne plus qu'à moitié. Je ne parviens absolument pas à démêler ce qui va partir en cache, quel type de cache, quand, pourquoi. Je teste des inclusions multiples à l'aveuglette. Tout ça pour utiliser une malheureuse variable de session. Il arrive même qu'ordonner à répétition un "recalcul" ne recalcule rien du tout. Caché c'est caché...

Je vais essayer de mettre en œuvre ce plugin, merci pour cette piste.

Erka.

JLuc

_______________________________________________
liste spip
spip@rezo.net - désabonnement : envoyer un mail à spip-off@rezo.net

Archives : https://www.mail-archive.com/spip@rezo.net/maillist.html

Infos : http://listes.rezo.net/mailman/listinfo/spip

Documentation de SPIP : http://www.spip.net/

Irc : de l'aide à toute heure : http://spip.net/irc

_______________________________________________
liste spip
spip@rezo.net - désabonnement : envoyer un mail à spip-off@rezo.net

Archives : https://www.mail-archive.com/spip@rezo.net/maillist.html

Infos : http://listes.rezo.net/mailman/listinfo/spip

Documentation de SPIP : http://www.spip.net/

Irc : de l'aide à toute heure : http://spip.net/irc

_______________________________________________
liste spip
spip@rezo.net - désabonnement : envoyer un mail à spip-off@rezo.net

Archives : https://www.mail-archive.com/spip@rezo.net/maillist.html

Infos : http://listes.rezo.net/mailman/listinfo/spip

Documentation de SPIP : http://www.spip.net/

Irc : de l'aide à toute heure : http://spip.net/irc