Author: esj@rezo.net
Date: 2008-09-08 12:06:48 +0200 (lun, 08 sep 2008)
New Revision: 12565
Log:
Il est dit dans le code que laisser 'fond' dans le contexte risque de créer un bouclage à l'inclusion.
Modified:
spip/ecrire/public/assembler.php
spip/ecrire/public/cacher.php
j'insiste,
je ne sais pas comment ça marche chez vous, mais avec un spip de base
toutes les urls /spip.php?articlexx, /spip.php?rubriqueyy etc ...
donnent la meme page en cache ...
autrement dit, j'ai plus de site là ... 
Cédric
Le 8 sept. 08 à 12:06, esj@rezo.net a écrit :
Author: esj@rezo.net
Date: 2008-09-08 12:06:48 +0200 (lun, 08 sep 2008)
New Revision: 12565Log:
Il est dit dans le code que laisser 'fond' dans le contexte risque de créer un bouclage à l'inclusion.Modified:
spip/ecrire/public/assembler.php
spip/ecrire/public/cacher.phpDetails: http://trac.rezo.net/trac/spip/changeset/12565
_______________________________________________
spip-commit@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-commit
dev: http://trac.rezo.net/trac/spip/
Le 8 sept. 08 à 12:26, cedric.morin@yterium.com a écrit :
j'insiste,
je ne sais pas comment ça marche chez vous, mais avec un spip de base
toutes les urls /spip.php?articlexx, /spip.php?rubriqueyy etc ...
avec les memes urls je n'ai pas le pb, je viens de réessayer.
Committo,Ergo:Sum
oui mais du coup la L192 de public/cacher ne connait plus fond, et les modeles sont mis en cache
Le 8 sept. 08 à 12:06, esj@rezo.net a écrit :
Author: esj@rezo.net
Date: 2008-09-08 12:06:48 +0200 (lun, 08 sep 2008)
New Revision: 12565Log:
Il est dit dans le code que laisser 'fond' dans le contexte risque de créer un bouclage à l'inclusion.Modified:
spip/ecrire/public/assembler.php
spip/ecrire/public/cacher.phpDetails: http://trac.rezo.net/trac/spip/changeset/12565
_______________________________________________
spip-commit@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-commit
dev: http://trac.rezo.net/trac/spip/
je ne vois pas comment cela pouvait marcher :
cela produisait pour tout contexte
array('lang'=>'fr',
'articlexx'=>'')
et dans le calcul du cache, on ne prend en compte, dans le nom du fichier, que les valeurs du contexte, et pas les clés
De toute facon la methode de calcul du nom n'assurait pas l'unicite en fonction du contexte, je l'ai donc reinjecte dans le calcul du md5
Cédric
Le 8 sept. 08 à 12:31, Committo,Ergo:sum a écrit :
Le 8 sept. 08 à 12:26, cedric.morin@yterium.com a écrit :
j'insiste,
je ne sais pas comment ça marche chez vous, mais avec un spip de base
toutes les urls /spip.php?articlexx, /spip.php?rubriqueyy etc ...avec les memes urls je n'ai pas le pb, je viens de réessayer.
Committo,Ergo:Sum
_______________________________________________
spip-commit@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-commit
dev: http://trac.rezo.net/trac/spip/
Le 8 sept. 08 à 13:03, cedric.morin@yterium.com a écrit :
je ne vois pas comment cela pouvait marcher :
cela produisait pour tout contexte
array('lang'=>'fr',
'articlexx'=>'')et dans le calcul du cache, on ne prend en compte, dans le nom du fichier, que les valeurs du contexte, et pas les clés
oui mais comme on prend en compte le nom de la page (et dans le cas des urls page il contient le numéro) le nom des clés n'a pas d'importance: pour une page donnée, les clés sont toujours les mêmes, et d'ailleurs dans la version précédente elles étaient mises (dans le corps du foreach) puis enlevées ensuite (par un preg_replace) ce qui faisait du calcul vraiment inutile.
De toute facon la methode de calcul du nom n'assurait pas l'unicite en fonction du contexte, je l'ai donc reinjecte dans le calcul du md5
Ca ca me va. Je pense que le pb était dans le test "strlen > 24" et les troncatures qui s'ensuivent: si le Path de la page était à lui seul > 24, les derniers caractères de articleXXX sautaient probablement.
Committo,Ergo:Sum
Le 8 sept. 08 à 13:14, Committo,Ergo:sum a écrit :
Le 8 sept. 08 à 13:03, cedric.morin@yterium.com a écrit :
je ne vois pas comment cela pouvait marcher :
cela produisait pour tout contexte
array('lang'=>'fr',
'articlexx'=>'')et dans le calcul du cache, on ne prend en compte, dans le nom du fichier, que les valeurs du contexte, et pas les clés
oui mais comme on prend en compte le nom de la page (et dans le cas des urls page il contient le numéro)
heu, je vois vraiment pas ou, la ..
avec
http://localhost/fraichdist/spip.php?article341
j'ai page = 'sommaire/fraichdist/spip.php' car on enleve toute la query string
le nom des clés n'a pas d'importance: pour une page donnée, les clés sont toujours les mêmes, et d'ailleurs dans la version précédente elles étaient mises (dans le corps du foreach) puis enlevées ensuite (par un preg_replace) ce qui faisait du calcul vraiment inutile.
De toute facon la methode de calcul du nom n'assurait pas l'unicite en fonction du contexte, je l'ai donc reinjecte dans le calcul du md5
Ca ca me va. Je pense que le pb était dans le test "strlen > 24" et les troncatures qui s'ensuivent: si le Path de la page était à lui seul > 24, les derniers caractères de articleXXX sautaient probablement.
oui dans le cas ou on mettait aussi le nom des cles, elles etaient de toute façon tronqueés
Cédric
Le 8 sept. 08 à 13:25, cedric.morin@yterium.com a écrit :
Le 8 sept. 08 à 13:14, Committo,Ergo:sum a écrit :
on prend en compte le nom de la page (et dans le cas des urls page il contient le numéro)
heu, je vois vraiment pas ou, la ..
avec
http://localhost/fraichdist/spip.php?article341
j'ai page = 'sommaire/fraichdist/spip.php' car on enleve toute la query string
Ah oui zut, c'est aux URL html que je pensais, je n'ai plus pensé à celles-là. Mea maxima culpa.
In fine, les pbs de doublons de cache sont évacués, le code est expurgé de calcul inutile et le nom d'un cache semble bien univoque.
Mais ça me fait tout de même bizarre qu'on doive tenir compte de la globale "$fond" qui, à ce moment du calcul, n'a peut-être pas sa valeur définitive puisque les URLs symboliques vont la changer par la suite. Evidemment le rôle du cache est AUSSI de ne pas calculer cette valeur mais je trouve ça assez contre-intuitif, je voulais vraiment trouver qqch de plus transparent. Tant pis.
Committo,Ergo:Sum