Bonjour,
Je suis en recherche d’un plugin permettant de fixer une date d’ancienneté pour le cache des images.
En effet, il existe pour le cache général une variable _DUREE_CACHE_DEFAUT.
Je souhaite utiliser un plugin permettant d’ajouter une variable _DUREE_CACHE_IMAGE_DEFAUT afin de gagner un peu de place sur mon serveur.
Quelqu’un aurait-il développé cet outil ?
Bonjour,
un tel plugin serai très consommateur à chaque fois.
Par contre il existe depuis peu une commande spip-cli pour cela, si ma mémoire est bonne.
Si tu es un peu à l’aise en ligne de commande, un simple find -mtime ... programmé en crontab du système ?
Merci pour vos retours, dans le cadre d’un serveur avec une quinzaine de Spip mutualisés, je penche pour m’inspirer de ce code : taches_generales_cron - Programmer avec SPIP 4 pour réaliser cette tâche.
@maieul tu soulèves un point auquel je n’avais pas réfléchi. Tu penses qu’économiser des Go de cache-vignettes et cache-gd est moins écologique que d’économiser le recalcul desdites vignettes. Malheureusement, OVH facture ses Go d’espace sur le VPS, et non la conso de ses processeurs. Et c’est sur ce point que mon serveur commence à atteindre une limite.
@Yohooo ce n’est pas seulement le calcul des vignettes qui pose des problèmes, c’est aussi simplement de retrouver les fichiers. Il faut en effet parcourir les dossiers pour rechercher les images obsolètes, de manière arborescente.
Hors si tu gère cela en cron spip, comme tu l’envisage, tu risque tout simplement de ne pas arriver à ton but : le cron spip étant executé au moment d’une requete depuis un navigateur, il ne peut pas faire des calculs trop complexes/trop long.
Ce n’est pas pour rien que c’est une commande spip-cli qui a été envisagée et incorporée : tu la passe une fois de temps en temps en ligne de commande, et là tu n’est pas limité par le timeout de php.
La commande spip-cli a été défini ici feat: une commande cli pour purger les images cache trop anciennes (cache-gd2 et cache-vignettes) (!4736) · Requêtes de fusion · spip / images · GitLab
Donc plutot que de chercher tout les X heures les fichiers les plus vieux, tu les recherche une fois de temps en temps, quand tu sens que tu arrive à ta limite.
+1, et si tu utilises un cron serveur comme le proposait @nicod tu n’auras plus à t’occuper de l’appel à cette commande cli 
C’est très juste et sûrement mieux, mais il resterait possible de passer par le cron de SPIP en demandant juste un petit boulot, pas la grosse commission (« tout » effacer).
Par exemple :
do (10 fois de suite) {
trouve 1 fichier ancêtre ;
efface-le ;
} thats_all ;
Dac c’est bien cette ouverture car parfois ya pas le choix ; mais ça serait quand même plus efficace de demander au système de s’en occuper via un cron serveur.
[EDIT] En cron SPIP, c’est intégré au code des plugins et facile à bouger en cas de changement d’hébergement : Hop dans l’unique transfert de code inclu avec le reste du ou des plugins, sans manip à part et sans devoir explorer l’interface d’un nouvel hébergeur.
… comme le fait par exemple « Nettoyer Révision », pour purger non les caches images, mais les tables des plus anciens fragments de révisions.
sauf qu’analyser des tables mysql classes ce n’est pas la même choses que parcourir des repertoirs
D’ailleurs Spip lui même a laisse tomber le fait de nettoyer son cache, se contentant de ne pas utiliser le cache perime :, parcourir des fichiers est consommateur.
Du reste en ce qui concerne le cache image il contient des images vieilles en grosse quantité qui ne serviront plus que dans 2 cas :
On est donc sur des besoins de nettoyage « One shot »
Et alors ?
Car à la base, SPIP a fait le choix de ne pas ranger les caches en BDD, mais de les enregistrer sous forme de fichiers… pour une meilleure efficacité !
ca depend le besoin : quand tu sais précisement où est-ce que tu cherche (typiquement pour trouver le cache d’un objet précis, on construit le chemin) mettre en fichier est plus rapide. Le problème là c’est qu’on ne sais pas précisement où se troiuve les objets qu’on cherche (les fichiers antérieurs à tel date). Il faut donc parcourir recursivement tout le dossier local/cache-gd2. Cf ce que fait la fonction cli. Et ca c’est plus compliqué.
plus compliqué en terme de perf, pas en terme programmatique.