[Résolu] 🧪 #SET avec #INCLURE & pas de cache

[Pierre_Jean]

Bonjour à toutes et à tous,

Je bloque sur l’assignation du résultat d’une inclusion à un #SET.
Mon inclusion renvoie un tableau sérialisé en faisant [(#GET{donnees}|serialize)].

En passant de l’écriture #INCLURE à <INCLURE>, rien ne va plus…

Contexte :

L’inclusion renvoie une sérialisation assez longue pour laquelle je souhaite bénéficier d’une mise en cache en passant par l’écriture <inclure> permettant de définir dans la noisette une durée de cache.

Ma page « appelante » se contente elle de produire un json : en faisant [(#GET{donnees}|unserialize|json_encode)] avec les données issues de mon inclusion.

Tests :

1. Si je fais , j’obtiens mes données sérialisées

[(#SET{donnees, [(#INCLURE{fond=mon_inclure})] })]

2. Si je fais , j’obtiens une erreur d’exécution

[(#SET{donnees, <INCLURE{fond=mon_inclure}> })]

Erreur transmise :

unserialize(): Error at offset 0 of 511 bytes in /var/www/monsite/ecrire/public/composer.php(94) : eval()'d code on line 36

J’ai aussi tente l’inclusion avec un paramètre {env} :

[(#SET{donnees,<INCLURE{fond=mon_inclure}{env}>})]

Dans ce cas, j’obtiens ces deux warnings :

• Trying to access array offset on value of type bool
• Array to string conversion

Questions :

1. Que faire !?
2. L’écriture avec <inclure> dans un #GET est-elle impossible ? Le compilateur ne gère pas ce cas ?

Merci pour votre aide bienvenue !

[b_b]

Une recherche « inclure set get » permet de trouver Performances cache <INCLURE> VS #INCLURE - #12 par JLuc

[JLuc]

Je sais pas si c’est le même problème, mais dans un cas assez similaire, l’inclusion renvoyait des caractères Unicode chaotiques (peut être bien du binaire) qui donnaient mal au core de SPIP et j’avais résolu le pb en passant le résultat de l’inclusion par un base64 qui remet tout dans le rang

Genre par un #FILTRE{base64_encode} à la fin du squelette #inclu, et un base64_decode à la réception l’#inclusion :

[(#SET{data_a,#INCLURE{fond=data_a,env}|base64_decode})]

Simplifié ici, ya un trim en plus avant de base64_encode.

[Pierre_Jean]

Merci pour vos retours,

Je passe maintenant par #INCLURE pour affecter le résultat de noisette à mon #SET.

Mon contexte est un appel à une api interne qui me renvoie de gros json dont la plupart tourne autour de 3Mo de données.

Mais le cache ne semble pas fonctionner, la lecture des entêtes montre que le date et last-modified changent à chaque hit.

J’ai aligné tous les caches de mes noisettes avec #CACHE{24*24*3600} mais rien n’y fait alors que mes pages plus « conventionnelles » sont-elles effectivement servies par le cache.

Que je tente de passer via un script js qui fait un fetch, ou bien en direct depuis le navigateur sur mon url qui produit les json, pas de cache !

Y a t’il une limitation de poids de fichiers ou encore de format pour le cache ?

Comment pourrais-je poursuivre les investigations sur ce cache qui ne fonctionne pas ?

Je n’utilise à ce stade que le cache natif en SPIP 4.x.

Merci encore pour vos lumières.

[Pierre_Jean]

Merci ! Intéressant, j’ai peut-être un problème similaire qui s’ajoute car le résultat de mon inclusion renvoie un array (que je sérialise) avant de transmettre au #SET de mon squelette parent.

Peut-être une piste pour mon problème de cache non fonctionnel sur ces noisettes…

[Pierre_Jean]

Désolé pour le bruit, mais c’était une fausse alerte…

J’ai honte, il s’agissait d’un vieux define define('_NO_CACHE', -1);dans une dépendance de plugin resté au stade de prototype…

Je m’en suis rendu compte en installant le couple Memoïzation + XRay qui nécessitait d’ajouter l’option define('_CACHE_KEY', '');

…

Encore une fois, merci à vous pour l’éclairage très intéressant sur le settage de résultats d’inclure !

[Christian_Marget]

Bonjour,

Pour récupérer des paramètres d’un squelette inclus, j’ai essayé la
méthode inspirée par Pierre-Jean. Je récupère bien un tableau sérialisé
mais pas moyen d’en extraire une valeur de façon «classique».

Le 20/02/2025 à 16:00, Pierre-Jean via Discuter de SPIP a écrit :

Mon inclusion renvoie un tableau sérialisé en faisant
[(#GET{donnees}|serialize)].
…
Ma page « appelante » se contente elle de produire un json : en faisant
|[(#GET{donnees}|unserialize|json_encode)]| avec les données issues de
mon inclusion.

Par exemple, mon inclusion contient ça:
#SET{param, #ARRAY{
p1,10,
p2,20,
p3,30,
p4,40,
}}[(#GET{param}|serialize)]

ou encore ça (le résultat est le même):
[(#SET{param, #ARRAY{
p1,10,
p2,20,
p3,30,
p4,40,
}|serialize})]#GET{param}

Si je l’appelle depuis ma page principale, je retrouve bien le contenu
sérialisé mais si j’essaie d’extraire une valeur, je n’obtiens rien:

[(#SET{param, <INCLURE{fond=mon_inclusion}>})]

param inclus = #GET{param}
p1 = #GET{param/p1,vide}

me donne :
param inclus =
a:4:{s:2:« p1 »;s:2:« 10 »;s:2:« p2 »;s:2:« 20 »;s:2:« p3 »;s:2:« 30 »;s:2:« p4 »;s:2:« 40 »;}
p1 = vide

Et si j’essaie de dé-sérialiser le tableau, j’ai une erreur
[(#SET{toto, #GET{param}|unserialize})]
→ Warning: unserialize(): Error at offset 0 of 245 bytes in
/(racine)/ecrire/public/composer.php(96) : eval()'d code on line 69

Pourtant, si je déclare param directement dans la page appelante au lieu
de l’inclure, ça marche et je peux le dé-sérialiser sans problème:
[(#SET{param, #ARRAY{
p1,1,
p2,2,
p3,3,
p4,4,
}|serialize})]

param_direct = #GET{param}
p1 = #GET{param/p1,vide}

me donne bien:
param_direct =
a:4:{s:2:« p1 »;s:2:« 10 »;s:2:« p2 »;s:2:« 20 »;s:2:« p3 »;s:2:« 30 »;s:2:« p4 »;s:2:« 40 »;}
p1 = 10

Qu’est-ce qui manque ?

Christian

[Pierre_Jean]

Bonjour Christian,

Il me semble que tu te heurtes au même problème que moi en tentant de faire un SET d’une noisette via l’écriture <inclure>.

Essaye avec l’écriture #INCLURE au lieu de <inclure> et tout devrait aller mieux

Chez moi par exemple :

[(#SET{informations, [(#INCLURE{fond=inc/meta/article, env})]})]

[Christian_Marget]

Le 24/03/2025 à 16:17, Pierre-Jean via Discuter de SPIP a écrit :> Il me
semble que tu te heurtes au même problème que moi en tentant de

faire un SET d’une noisette via l’écriture ||.

Essaye avec l’écriture |#INCLURE| au lieu de || et tout devrait
aller mieux

Effectivement, ça passe mieux. Quand tu avais parlé de « fausse alerte »,
je croyais que tu avais résolu ce problème, je n’avais pas compris que
ça concernait le cache.

Par contre si je comprends bien, ça refait le calcul à chaque appel au
lieu de le garder en cache, dommage.

Merci de ton aide
Christian