Bugs et trucs

La clé binaire se sauve pas en BDD
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.

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 Le cache sans _ est quasi vide  : il ne contientque 2 entrées contient toujours que :
<code>[invalideurs] code>Array ([ invalideurs] => Array ( [session] => ’’)</code > et < code>[lastmodified] ’’), [lastmodified] => 1540217689</code 1540217689)</code >
-  Mais parfois , le Le cache sans avec _ est identique au cache avec _, à ceci près consulté prés de 2 fois plus souvent que la version avec celui sans _ ( 3281 / dispose d’un invalideur < code>[session] 2438 ) =>’’ 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 (?)

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.