Bonjour,
Je travaille avec la 1.8b1 CVS de ce matin
Il semble que l'utilisation du cache soit un peu agressive. Visiblement le PHP contenu dans mes pages ne s'exécute pas lorsqu'elle est en cache (vérifié avec un appel à spip_log dans mon code php).
Cordialement
PS: désolé de ne pouvoir donner d'URL mais je suis en local
Il semble que l'utilisation du cache soit un peu agressive.
Visiblement le PHP contenu dans mes pages ne s'exécute pas lorsqu'elle
est en cache (vérifié avec un appel à spip_log dans mon code php).
Tu l'appelles comment ton php ? Normalement SPIP détecte les <? pour
décider de passer en php.
-- Fil
<?php truc(); ?>
>> Il semble que l'utilisation du cache soit un peu agressive.
>>Visiblement le PHP contenu dans mes pages ne s'exécute pas lorsqu'elle
>>est en cache (vérifié avec un appel à spip_log dans mon code php).
>
>Tu l'appelles comment ton php ? Normalement SPIP détecte les <? pour
>décider de passer en php.<?php truc(); ?>
Zut, je n'ai pas ce bug chez moi !
As-tu bien vidé le cache ? Normalement le fichier cache doit contenir, sur
le première ligne, une carte d'identité indiquant qu'il s'agit de php :
Exemple :
<!-- a:1:{s:11:"process_ins";s:3:"php";} -->
<?php echo("uu"); ?>
-- Fil
Précisions :
1. Ça n'est pas systématique
2. Je suis sûr que ça ne vient pas du cache du navigateur, en simultané j'ai un tail -f de spip.log qui tourne
Voilà ce que j'ai
j'ai un squelette message.html dans lequel j'ai mis un spip_log("execution de message.html"); et un squelette inclus observer.html dans lequel j'ai mis un spip_log("execution de observer.html");
1. Je vais sur une page qui n'est pas en cache : http://localhost/spip/message113463.html
sortie de spip_log
Sep 02 11:46:43 127.0.0.1 (pid 1346) calcul (0.28s): CACHE/a/spip-message113463.85719353.gz
Sep 02 11:46:43 127.0.0.1 (pid 1346) execution de message.html
Sep 02 11:46:44 127.0.0.1 (pid 1346) test CACHE/e: flock ok
Sep 02 11:46:44 127.0.0.1 (pid 1346) calcul inclus (0.70s): CACHE/e/avatar-7348-avatar.9549bc10.gz
Sep 02 11:46:44 127.0.0.1 (pid 1346) calcul inclus (0.65s): CACHE/c/avatar-5481-avatar.c36a2ad0.gz
Sep 02 11:46:45 127.0.0.1 (pid 1346) calcul inclus (0.71s): CACHE/c/avatar-8934-avatar.b27ab48f.gz
Sep 02 11:46:45 127.0.0.1 (pid 1346) premier acces: CACHE/c/avatar-8934-avatar.b27ab48f.gz (.NEW)
Sep 02 11:46:45 127.0.0.1 (pid 1346) premier acces: CACHE/c/avatar-5481-avatar.c36a2ad0.gz (.NEW)
Sep 02 11:46:46 127.0.0.1 (pid 1346) calcul inclus (0.63s): CACHE/a/avatar-5150-avatar.b0a072e1.gz
Sep 02 11:46:46 127.0.0.1 (pid 1346) test CACHE/7: flock ok
Sep 02 11:46:46 127.0.0.1 (pid 1346) calcul inclus (0.01s): CACHE/7/observer-113463-observer.aff739d0.gz
Sep 02 11:46:46 127.0.0.1 (pid 1346) execution de observer.html
2. dans cette page je clique un lien qui rappel la page avec un argument :
http://localhost/spip/message113463.html?abonnement=oui
sortie de spip_log
Sep 02 11:47:56 127.0.0.1 (pid 311) calcul (0.29s): CACHE/6/463%3Fabonnement%3Doui.9765580f.gz
Sep 02 11:47:56 127.0.0.1 (pid 311) execution de message.html
Sep 02 11:47:56 127.0.0.1 (pid 311) calcul inclus (0.51s): CACHE/f/niers_messages_article.7bc3886b.gz
Sep 02 11:47:56 127.0.0.1 (pid 311) premier acces: CACHE/e/avatar-7348-avatar.9549bc10.gz (.NEW)
Sep 02 11:47:56 127.0.0.1 (pid 311) premier acces: CACHE/a/avatar-5150-avatar.b0a072e1.gz (.NEW)
Sep 02 11:47:56 127.0.0.1 (pid 311) premier acces: CACHE/7/observer-113463-observer.aff739d0.gz (.NEW)
Sep 02 11:47:56 127.0.0.1 (pid 311) execution de observer.html
Sep 02 11:47:56 127.0.0.1 (pid 311) INSERT INTO suivi_forums_auteurs (id_auteur,id_forum) VALUES (1,113463)
3. je reclique un lien dans cette même page :
http://localhost/spip/message113463.html?abonnement=non
sortie de spip_log
Sep 02 11:49:02 127.0.0.1 (pid 1346) calcul (0.30s): CACHE/e/463%3Fabonnement%3Dnon.0d4da8e1.gz
Sep 02 11:49:02 127.0.0.1 (pid 1346) execution de message.html
Sep 02 11:49:03 127.0.0.1 (pid 1346) premier acces: CACHE/f/niers_messages_article.7bc3886b.gz (.NEW)
Sep 02 11:49:03 127.0.0.1 (pid 1346) execution de observer.html
Sep 02 11:49:03 127.0.0.1 (pid 1346) DELETE FROM suivi_forums_auteurs WHERE id_auteur=1 AND id_forum=113463
Je reclique le lien précédent :
http://localhost/spip/message113463.html?abonnement=oui
sortie de spip_log
Sep 02 11:49:46 127.0.0.1 (pid 1345) indexation forum 10094
Sep 02 11:49:46 127.0.0.1 (pid 1345) -> indexation thread 10094,10131,12050
ce qui n'est pas normal 
bien évidemment, en tête de mon squelette message.html j'ai :
// Disable caching
@header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
@header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
@header("Cache-Control: no-store, no-cache, must-revalidate");
@header("Cache-Control: post-check=0, pre-check=0", false);
@header("Pragma: no-cache");
mais comme qq chose apparaît dans spip.log, on est sûr que ce n'est pas le cache du navigateur qui joue des tours
voili voilou
Il semble que l'utilisation du cache soit un peu agressive.
Visiblement le PHP contenu dans mes pages ne s'exécute pas lorsqu'elle
est en cache (vérifié avec un appel à spip_log dans mon code php).Tu l'appelles comment ton php ? Normalement SPIP détecte les <? pour
décider de passer en php.<?php truc(); ?>
Zut, je n'ai pas ce bug chez moi !
argh
As-tu bien vidé le cache ?
J'avais pas fait, je viens de le faire et de réessayer et c'est la même chose
Normalement le fichier cache doit contenir, sur
le première ligne, une carte d'identité indiquant qu'il s'agit de php :Exemple :
<!-- a:1:{s:11:"process_ins";s:3:"php";} -->
<?php echo("uu"); ?>
Oui j'ai bien se serialize en tête, exemple :
<!-- 3:"php";} --> dans CACHE/e/565\%3Fabonnement\%3Doui.3d148cb2.gz
C'est bizarre, j'ai plutot le souci inverse : tendance à faire des caches
identiques ... (quand il y a des parametres passés en GET pas directement
utilisés)
Ce que je ne comprends pas bien, c'est pourquoi une fonction sans parametre
ne devrait pas etre mise en cache ?
c'est basé sur le temps ? sur des variables globales ?
Est ce que la boucle est directement dans le squelette appelé ou dans un
squelette inclus (ce qui rend la gestion du cache beaucoup plus souple, tu
peux passer explicitement les parametres qui doivent etre pris en compte
dans le contexte pour le caclul du cache) ?
En tous cas, chez moi, si le type de cache est "php", le code est bien
utilisé à chaque fois ...
Tu ne serais pas derriere un proxy par hasard ?
Peux-tu nous faire passer un squelette simple sur lequel on puisse
reproduire ?
Merci, @++
C'est bizarre, j'ai plutot le souci inverse : tendance à faire des caches
identiques ... (quand il y a des parametres passés en GET pas directement
utilisés)
Oui, c'est le fonctionnement normal de SPIP, ça ; c'est assez difficile de
faire mieux sans toucher à l'existant (il faudrait faire une liste
exhaustive des paramètres qui peuvent affecter une page, à supprimer dans
la fonction nettoyer_uri() ). Mais sur ce point je pense qu'il y a pas mal
d'améliorations possibles.
-- Fil
C'est bizarre, j'ai plutot le souci inverse : tendance à faire des caches
identiques ... (quand il y a des parametres passés en GET pas directement
utilisés)
Ce que je ne comprends pas bien, c'est pourquoi une fonction sans parametre
ne devrait pas etre mise en cache ?
Mais je veux qu'elle soit mise dans le cache. Par contre je voudrais que mon PHP soit exécuté
c'est basé sur le temps ? sur des variables globales ?
sur $auteur_session
Est ce que la boucle est directement dans le squelette appelé ou dans un
squelette inclus (ce qui rend la gestion du cache beaucoup plus souple, tu
peux passer explicitement les parametres qui doivent etre pris en compte
dans le contexte pour le caclul du cache) ?
En tous cas, chez moi, si le type de cache est "php", le code est bien
utilisé à chaque fois ...
Tu ne serais pas derriere un proxy par hasard ?
non, c'est en local
Peux-tu nous faire passer un squelette simple sur lequel on puisse
reproduire ?
je suis en train d'essayer mais je n'y arrive pas 
Toutefois, j'ai quasiment vidé mon squelette message.html et le pb persiste
voilà le test fait et le spip.log -
le test : vidage du cache puis affichage répétitif de message116136.html
spip.log:
Sep 02 16:50:10 127.0.0.1 (pid 1348) vider le cache
Sep 02 16:50:22 127.0.0.1 (pid 1348) calcul skel message2.html (0.03s)
Sep 02 16:50:22 127.0.0.1 (pid 1348) calcul (0.16s): CACHE/a/spip-message116136.faaaaee7.gz
Sep 02 16:50:22 127.0.0.1 (pid 1348) execution de message.html
Sep 02 16:50:22 127.0.0.1 (pid 1348) calcul skel observer.html (0.01s)
Sep 02 16:50:22 127.0.0.1 (pid 1348) calcul inclus (0.03s): CACHE/4/observer-116136-observer.3830a3b6.gz
Sep 02 16:50:22 127.0.0.1 (pid 1348) execution de observer.html
Sep 02 16:50:29 127.0.0.1 (pid 1345) premier acces: CACHE/a/spip-message116136.faaaaee7.gz (.NEW)
Sep 02 16:50:29 127.0.0.1 (pid 1345) execution de message.html
Sep 02 16:50:29 127.0.0.1 (pid 1345) premier acces: CACHE/4/observer-116136-observer.3830a3b6.gz (.NEW)
Sep 02 16:50:29 127.0.0.1 (pid 1345) execution de observer.html
Sep 02 16:50:33 127.0.0.1 (pid 1345) indexation forum 10644
Sep 02 16:50:33 127.0.0.1 (pid 1345) -> indexation thread 10644,10668,10823,10834,10838,10840,10842,10846,10848,10854,10865,10868,10875,10878,10883,10889,10891,10914,10915,10918,10923,10924,10927,10928,10929,10931,10935,10938,10940,10969,10974,10975,10996,11054,11058,11063,11066,11084,11091,11118,11154,11167,11197,16246
Sep 02 16:50:37 127.0.0.1 (pid 1347) execution de message.html
Sep 02 16:50:37 127.0.0.1 (pid 1347) execution de observer.html
Sep 02 16:50:41 127.0.0.1 (pid 1347) indexation forum 10647
Sep 02 16:50:41 127.0.0.1 (pid 1347) -> indexation thread 10647,10862,10863,10866,14801,15011,15014,19400
Sep 02 16:50:44 127.0.0.1 (pid 1346) execution de message.html
Sep 02 16:50:44 127.0.0.1 (pid 1346) execution de observer.html
Sep 02 16:50:48 127.0.0.1 (pid 1346) indexation forum 10663
Sep 02 16:50:48 127.0.0.1 (pid 1346) -> indexation thread 10663,10669
=> c'est ok, le php est exécuté
ensuite, clic sur la résiliation de l'abonnement (message116136.html?abonnement=non)
Sep 02 16:52:17 127.0.0.1 (pid 311) calcul (0.08s): CACHE/f/136%3Fabonnement%3Dnon.77405d52.gz
Sep 02 16:52:17 127.0.0.1 (pid 311) execution de message.html
Sep 02 16:52:17 127.0.0.1 (pid 311) execution de observer.html
Sep 02 16:52:17 127.0.0.1 (pid 311) DELETE FROM suivi_forums_auteurs WHERE id_auteur=1 AND id_forum=116136
clic sur abonnement (message116136.html?abonnement=oui)
Sep 02 16:52:24 127.0.0.1 (pid 1348) calcul (0.08s): CACHE/2/136%3Fabonnement%3Doui.6d56a929.gz
Sep 02 16:52:24 127.0.0.1 (pid 1348) execution de message.html
Sep 02 16:52:24 127.0.0.1 (pid 1348) execution de observer.html
Sep 02 16:52:24 127.0.0.1 (pid 1348) INSERT INTO suivi_forums_auteurs (id_auteur,id_forum) VALUES (1,116136)
clic sur résiliation (message116136.html?abonnement=non)
Sep 02 16:52:29 127.0.0.1 (pid 1345) indexation forum 10664
Sep 02 16:52:29 127.0.0.1 (pid 1345) -> indexation thread 10664,10667,10716,10725,10765,10767,10793
=> pas d'exécution du PHP ce coup ci et à partir de là, l'enchaînement oui/non n'engendre plus d'exécution du PHP
(note, il y une réécriture d'URL :
Rewriterule ^message([0-9]+)\.html$ message.php3?id_forum=$1&debut_message=0 [QSA,L]
J'ai essayé sans réécriture d'URL avec le même résultat
Voici les fichiers de squelette :
message.php3 (83 Bytes)
message2.html (837 Bytes)
observer.html (4.17 KB)
observer.php3 (83 Bytes)
>>> Il semble que l'utilisation du cache soit un peu agressive.
>>>Visiblement le PHP contenu dans mes pages ne s'exécute pas lorsqu'elle
>>>est en cache (vérifié avec un appel à spip_log dans mon code php).
Voilà, après debug intensif avec Jean-Luc, c'est qu'il manquait un test sur
$flag_dynamique avant d'envoyer l'entete Last-Modified: (inc-public-global),
et que JL avait oublié de mettre flag_dynamique dans son fichier d'appel.
-- Fil
Pour info :
phpMyVisites est un logiciel libre, distribué sous licence GNU/GPL. Vous
pouvez
trouver cette licence sur The GNU General Public License v3.0 - GNU Project - Free Software Foundation en version
originale, ou sur
http://www.linux-france.org/article/these/gpl.html en traduction non
officielle. Elles sont
aussi disponibles dans le package de phpMyVisites sur /docs/.
Ca a effectivement l'air tres bien ...
"Jacques PYRAT" <spip.newsgroup@pyrat.net> a écrit dans le message de
news:ch94an$crd$1@sea.gmane.org...
Matthieu Aubry wrote:
> Bonjour,
> Je suis l'auteur de phpMyVisites http://www.phpmyvisites.net/
> Croyez vous possible l'éventuelle intégration de phpMyVisites à SPIP ?
> En tant que module annexe ?
> Merci
> Matthieu
>
> démo : http://www.phpmyvisites.net/phpmyvisites/*Attention*: Ceci est un avis personnel qui n'engage en rien les dev
officiels et historiques de SPIP !En soit, le produit est très intéressant (assez semblable à Xiti, sans le
logo
Mais un prérequi pour son intégration à SPIP serait qu'il soit en GPL, ce
qui n'est pas le cas actuellement (ou alors, c'est bien caché sur le
site).
