[spip-dev] cache vignettes : images différentes entre espace public/privé

Bonjour,

Dans un squelette de l’espace public, j’affiche un logo de la manière suivante :
[(#LOGO_TRUC

image_reduire{1200})]

et dans un squelette de l’espace privé, je l’affiche d’une manière similaire :
[(#LOGO_TRUC

image_reduire{1200}
inserer_attribut{width, ‹ 100% ›}
inserer_attribut{height, ‹  ›}
inserer_attribut{alt, ‹  ›})]

Au final, je me retrouve avec 2 images :

  • public : src=« local/cache-vignettes/L1200xH900/trucon7738-d0d4e.jpg?1498902471 »

  • privé : src=« …/local/cache-vignettes/L1200xH900/trucon7738-a210a.jpg?1498902377 »

Retirer les « inserer_attribut » pour avoir exactement le même code ne change rien.

Est-ce un bug ?

Julien

Je sais pas si c'est un bug, mais je reproduis :slight_smile:

MM.

Matthieu Marcillaud a écrit le 02/07/2017 à 12:35 :

Oui, c'est bien ce que j’imaginais aussi.
J’ai même un patch là éventuellement.

Si on est dans l’espace privé et qu’on trouve _DIR_RACINE sur le chemin, on l’enlève (du coup on retombe sur le chemin comme si on était dans le public). À tester peut être. Mais effectivement c'est con de doubler l’espace disque pour des traitements identiques !

Index: ecrire/inc/filtres_images_lib_mini.php

Ou, sans chercher l’espace où l’on est, se baser sur le chemin physique. C'est peut être mieux. On enlève _ROOT_RACINE de realpath($fichier), ce qui nous donne IMG/art1.png dans mon exemple aussi dans le public ou privé :

// partager les images calculées pour des traitements identiques dans l’espace public ou privé
$identifiant = $fichier;
if (strncmp($f = realpath($fichier), _ROOT_RACINE, strlen(_ROOT_RACINE)) == 0) {
     $identifiant = substr($f, strlen(_ROOT_RACINE));
}

Bon, j’ai envoyé cela https://core.spip.net/projects/spip/repository/revisions/23632 à tester tout de même.

Et finalement j’ai utilisé strpos qui est signalé plus rapide que strncmp dans cet usage (http://php.net/manual/fr/function.strncmp.php#121036).

MM.

Super Matthieu, je te remercie bcp !!

Avec autour de 250 000 photos sur un site, ça m’intéresse pas mal !

J’ai testé ton code en local et ça ne marche bien.

J’ai juste du faire une petite adaptation pour que fonctionne aussi en local sous windows…
Le coupable vient du ecrire/inc_version.php qui rajoute un “/” à la fin du _ROOT_RACINE.

Ce qui au niveau du code génère ceci :

_ROOT_RACINE => “C:…\localweb\projects\spip3/” => un slash final inversé pour windows
realpath($fichier) => “C:…\localweb\projects\spip3\IMG\arton9306.jpg”

et donc le “strpos” ne passe pas.

Pb sous windows uniquement donc.

…qu’on peut résoudre comme ça :

// rtrim : éviter le mélange des ‘/’ et ‘’ sous windows…
if (strpos($f = realpath($fichier), rtrim(_ROOT_RACINE, ‘/’)) === 0) {
$identifiant = substr($f, strlen(_ROOT_RACINE));
}

pour que ça fonctionne partout.

Julien

Vu, merci. https://core.spip.net/projects/spip/repository/revisions/23633
Et du coup, c’est en attendant une meilleure correction (mais sur la prochaine version de dev, on va attendre que la 3.2 soit branchée).
https://core.spip.net/issues/3971

MM.

Bon, on a du annuler ces commits car cela cassait la reconstruction des images intermédiaires dans l’espace privé.
Le fichier .src de construction stockant les chemins relatifs aussi des images, qui est ensuite envoyé aux fonctions de traitement d’images s’il y a besoin de reconstruire l’image.
C'est un peu trop compliqué actuellement pour corriger/améliorer ce point.

https://core.spip.net/projects/spip/repository/revisions/23695

MM.

Comme ça va me poser problème, j’essaie de comprendre comment SPIP fonctionne.

J’ai lu https://code.spip.net/fr/archives/traitements-d-image/article/images-temporaires-images
…et je ne saisis pas vraiment les raisons de la mise en place de ces mécanismes.

Ce que je crois avoir compris :

Il existe 2 dossiers de stockage des vignettes :

  • cache_vignettes
  • cache_gd2

cache_vignettes sert pour stocker les images qui n’ont subi que des réductions (image_reduire/passe_partout)
cache_gd2 sert pour stocker les images qui ont subit des transformations (image_recadre/rotation/etc.)

Lorsqu’on enchaine des filtres d’images, l’image finale est donc stockée dans l’un de ces 2 dossiers de cache.
Cette image finale est appelée image permanente ou gravée. Cela signifie qu’elle est utilisée, i.e « affichée quelque part ».

Mais l’enchainement des filtres a également produit les images intermédiaires, chacune associée à un fichier « de contrôle » (.src) qui contient les « informations de reconstruction »…

Lorsque le processus grave l’image finale permanente, il supprime ensuite toutes les images intermédiaires mais laisse les fichiers de contrôle qui y étaient associés.

On a donc

  • aucune image intermédiaire mais à la place : des fichiers de contrôle
  • une image finale permanente sans fichier de contrôle.

Pour le cas, ou l’image subit une autre série de filtres dont certains sont communs, les fichiers de contrôle vont servir…
En reprenant l’exemple de la doc :

[(#TEXTE|image_reduire{520,0}

image_reduire{150}
image_rotation{90}
image_recadre{200,200,‹ center ›,‹ red ›}
image_aplatir{jpg}
)]
[(#TEXTE|image_reduire{520,0}
image_reduire{150}
image_rotation{-90}
image_recadre{200,200,‹ center ›,‹ red ›}
image_aplatir{jpg}
)]

Il est écrit :

Dans la deuxième série de filtres, les deux premiers filtres image_reduire ne font rien car les fichiers de contrôle sont là. Au moment de calculer le image_rotation, on s’aperçoit qu’il nous les faut. On reconstruit donc les deux images intermédiaires, et celle qui a manqué (la deuxième) est gravée car on sait qu’elle est commune à plusieurs séries.

Le gravage automatique de l’image intermédiaire évite un recalcul systématique pour cause de dates a chaque hit.

Ce que je n’arrive pas à comprendre :
La 2eme série de filtre provoque aussi une image finale permanente.
Des lors, à quoi bon stocker l’image temporaire commune au 2 séries ?
La raison invoquée est d’ « éviter un recalcul systématique pour cause de dates à chaque hit »

Dans quel cas y aurait-il un recalcul ? qu’est-ce que cette histoire de date ? un lien avec l’alea à la fin des urls d’images ?

Je vous remercie par avance.

Julien