Y compris avec $GLOBALS['derniere_modif_invalide'] = false et un
recalcul du cache demandé à minuit 5 pour des articles, ceux-ci sont
quelquefois recalculés avant la fin du délai.
#CACHE{24*3600, duree minuit id_article}
J'ai pu constater que le html en cache
(tmp/cache/nn/hhhlhlllshxcl.html) était quelquefois supprimé avant la
fin de validité de celui-ci.
Y compris avec $GLOBALS['derniere_modif_invalide'] = false et un
recalcul du cache demandé à minuit 5 pour des articles, ceux-ci sont
quelquefois recalculés avant la fin du délai.
Je cherche l'événement qui peut provoquer cela.
Un paramétrage permet d'en savoir plus sur les invalidations.
Ajoute dans ton fichier d'options : define ('LOG_INVALIDATION_CORE', true);
et plusieurs fichiers de logs seront générés, qui te donneront plus d'infos.
Dit moi s'il manque des infos ensuite.
> Cachelab + Memoization/filecache + jusqueminuit
> $GLOBALS['derniere_modif_invalide'] = false;
>
> Y compris avec $GLOBALS['derniere_modif_invalide'] = false et un
> recalcul du cache demandé à minuit 5 pour des articles, ceux-ci
> sont
> quelquefois recalculés avant la fin du délai.
> Je cherche l'événement qui peut provoquer cela.
Un paramétrage permet d'en savoir plus sur les invalidations.
Ajoute dans ton fichier d'options : define ('LOG_INVALIDATION_CORE',
true);
et plusieurs fichiers de logs seront générés, qui te donneront plus
d'infos.
Dit moi s'il manque des infos ensuite.
Bonjour,
Je n'ai pas eu le temps d'observer dans le détail et n'est donc pas
activé les logs avec define ('LOG_INVALIDATION_CORE', true); .
Cependant, un article avec le filtre jusqueminuit (pas de recalcul
avant le lendemain minuit) a été recalculé à chaque visite lors de la
journée du 27/01 .
Les visiteurs avaient tous la chaîne "googleweblight" dans le User
Agent.
J'ai changé le regex pour Google dans ecran_securite.php :
+ googlebot
- google
Par ailleurs, sur un article utilisant également le filtre
jusqueminuit, fréquemment visité par les humains et crawlé par Google
(plusieurs fois par jour quelquefois), les recalculs inopinés semble
toujours intervenir après une visite de Googlebot.
Je n'ai pas eu le temps d'observer dans le détail et n'est donc pas
activé les logs avec define ('LOG_INVALIDATION_CORE', true); .
ça donne toutes les raisons d'invalidation
mais dans ton cas peut être ça ne donnera rien d'intéressant.
Cependant, un article avec le filtre jusqueminuit (pas de recalcul
avant le lendemain minuit) a été recalculé à chaque visite lors de la
journée du 27/01 .
Les visiteurs avaient tous la chaîne "googleweblight" dans le User
Agent.
Au vu de tes divers témoignages on dirait que
tu transmet tout l'environnement reçu de l'url au squelette.
Du coup dès qu'il y a un argument paraisite (comme le fbclid auparavant)
il faut un nouveau cache qui doit être calculé.
Ce sont des calculs, pas des recalculs.
Pour éviter cela, il faudrait ne passer QUE les arguments strictement requis
à la noisette pour laquelle tu spécifies une durée de cache jusqueminuit.
Donc si c'est pas déjà fait, met ce bloc dans un <inclure>
et passe lui explicitement les seules infos dont il a besoin,
pas tout l'env.
J'ai changé le regex pour Google dans ecran_securite.php :
+ googlebot
- google
Ce serait à reporter dans le core.
Je vois aussi que les cartes leaflet passent très mal via google "web light".
J'ai changé le regex pour Google dans ecran_securite.php :
+ googlebot
- google
Ce serait à reporter dans le core.
Euh non, je crois qu'il pas qu'il faille le bannir avec l'écran,
car ce weblight ne sert pas à *indexer* le web, mais à le *consulter*,
et derrière chaque user-agent weblight il y a un utilisateur qui surfe sur android.