Bugs et trucs

Résidu de config obsolète nocive

Il est probable que le format des données de configuration de Memoization a changé au cours de son développement. Il semble qu’à une certaine étape de son enfance, Memoization distingait la mémoization des pages SPIP des autres mémoization, et positionnait la meta [Memoization][pages] en conséquence. Cette sous-config n’est plus paramétrable, MAIS ELLE EST TOUJOURS UTILISÉE par le code ! En conséquence, si elle vaut ’filecache’, il n’est plus possible d’utiliser Memoization QUE par filecache.
-  FIX manuel : Il faut supprimer cette entrée avec phpmyadmin et vider /tmp/metacache
-  TODO : vider cette entrée par un code d’upgrade de Memoization. Pour rien changer pour SPIP, elle est prioritaire.

La clé binaire se sauve pas en BDD sur certains hébergements
CACHE_KEY ne se sauve pas correctement sur une BDD, pourtant utf8, sur un site hébergé chez gandi. Du coup c’est vide quand on le récupère, et les caches ne sont pas cryptés. Ça ne se produit pas chez nursit par contre. C’est pas grave chez Gandi car les caches ne sont pas partagés mais sur un autre hébergement où ce problème se produit aussi et où les caches sont partagés, ce serait une faille sécu.

Disponibilité trompeuse
Sur un hébergement OVH mutu, le plugin détecte que memcached et memcache sont disponibles (ainsi que redis), mais en fait ils ne le sont pas.

Selon la doc OVH memcached est « non activable », bien que php soit configuré avec « ’—enable-memcached ». Quand on active le plugin avec Memcached, le site fonctionne quand même, mais rame (30 secondes pour servir une page). Avec memcache, il ne rame pas autant mais met 2 fois plus de temps qu’avec filecache pour servir une page.

Le test de disponibilité devrait être plus précis.

creer_cache

creer_cache appelle maj_invalideurs *aprés* avoir enregistré le cache, ce qui empêche à maj_invalideurs de modifier le cache en modifiant simplement le paramètre &$page reçu (comme le ferait un pipeline). Serait il possible d’appeler maj_invalideurs *avant* l’enregistrement du cache ?

Caches dont la clé se termine par _
Pour certains squelettes, memoization produit des paires de caches jumeaux : l’un suffixé par _, l’autre pas.
-  Ces caches ont toujours une entrée [invalideurs][session] mais vide.
-  Souvent, le cache sans _ ne contientque 2 entrées :
[invalideurs] => Array ( [session] => '') et [lastmodified] => 1540217689
-  Mais parfois, le cache sans _ est identique au cache avec _, à ceci près que la version avec _ dispose d’un invalideur [session]=>'' supplémentaire et que les 2 versions ne sont pas créées au même moment et donc les variables de dates changent (contexte #DATE et #DATE_REDAC + index lastmodified)
-  Le cache avec _ est consulté plus souvent que celui sans _ (exemple : 3281 / 2438), mais peut être cela dépend il du profil de visiteurs du site.
-  Parfois, il existe aussi une version avec un id_session non vide pour certains de ces caches.

Cela semble associé au fait que Mémoization teste seulement isset($cache['invalideurs']['session']) et non si la valeur est non-vide, pour ajouter le suffixe ’_idsession’. Tous ces caches ont une entrée $cache['invalideurs']['session'] dont la valeur est vide, et ça crée donc le suffixe ’_’.

Hypothèses :
-  le cache sans _ qui ne contient presque rien est une erreur de création (ou de test), et n’est pas utilisé. On peut ne pas le créer. (?)
-  le cache sans _ qui contient presque rien a une fonction annexe, comme un marqueur intermédiaire (?)
-  ce sont les caches non sessionnés d’internautes logés (?)