controlleur fournisseurs.

eolia

On est d'accord que le test sur le format medium est un reste de l'historique et qu'il est inutile.
Dans tous cas il n'est pas nécessaire de toucher au controleur à mon avis car si vous avez l'id du supplier vous connaissez son image de base donc
<img src="{$img_sup_dir}{$supplier.id}-medium_default.jpg" alt="" width="{$mediumSize.width}" height="{$mediumSize.height}" /> doit vous suffire.
Même si c'est du png l'extension sera jpg.

herve_02

@eolia
le seul truc c'est que si l'image n'existe pas on ne le sait pas, on affiche à l'aveugle. là le controleur répond image ou pas d'image.

si on modifie juste une fonction dans une classe et/ou un contrôleur est qu'on peut mettre en overide la classe et le contoleur avec juste la fonction qui a bougée ? je re-regarderais dans le bouquin prestashop 1.6

eolia

Oui vous pouvez dans une override ne mettre que la fonction à modifier ou à ajouter. Elle sera lu en priorité.

Je vous joins la proposition du contrôleur pour la v37. Je teste la présence de l'image de base et je teste les formats (indépendamment du thème). Si l'un manque je les regénère.
Et je vais faire pareil pour les fabricants/marques.
SupplierController.php

herve_02

@eolia
je trouve cela parfait..

herve_02

@eolia

mais du coup, comme les images existent à chaque fois, puisque à chaque vérification d'images on les crée toutes (enfin celles qui manqueraient) est-ce que cela vaut la peine de garder le(s) rewrite apache (et le script php) qui fabrique l'image si elle n'existe pas?
Il y aurait peut être une race conditions : l'image qui serait fabriquée après avoir été appelé dans le tpl ? même si j'ai l'impression que dans le contrôleur , les choses étant séquentielles, elles seraient fabriquées avant de donner la main au tpl ?

est-ce que ce gain de temps et de cpu serait significatif ? Probablement pas à notre niveau de fréquentation où les robots fréquentent plus que les humains (d'ailleurs je suis presque certain que la fabrication des images manquantes se fait à la visite des robots) et le secteur de marché est "restreint" et une large majorité des visiteurs sont des acheteurs (ce site doit exister depuis 10-15 ans au moins) .Je pense, comme lu dans une de vos interventions, c'est surtout les appels mariadb qui occupent la majeure partie du temps. (je n'ai pas encore activé le cache (recompilation à chaque fois) ET le concaténation des JS et CSS)
j'ai encore quelques millisecondes à gagner, sans efforts

eolia

Pas tout à fait parfait, je viens de rajouter des contrôles (si la génération échoue).
Le fait d'affecter le $image = $this->context->language->iso_code.'-default'; évite justement de passer par le contrôleur not_found qui va tester le chemin et renvoyer la même chose au final.
Sachant que ce contrôleur gère tout ce qui est non trouvé y compris les images.

eolia

ManufacturerController.php
SupplierController.php

herve_02

@eolia la je pînaile et je suis même pas certain de comprendre toutes les subtilités...

if(!file_exists(_PS_SUPP_IMG_DIR_.$this->supplier->id.'-'.stripslashes($image_type['name']).'.jpg')) {
                       if(!$this->generateFormats($this->supplier->id, $images_types)) {
                           $image = $this->context->language->iso_code.'-default';
                       }
                       break;
                   }

De ce que je comprends si j'ai pas l'image de base directement ==> défault.
si j'ai une image de base on va boucler sur toutes les images censée exister ImageType::getImagesTypes('suppliers') et tenter de les fabriquer... si elles n'existent pas.

je n'ai pas compris le break on fabrique la première image qui n'existe pas ou on fait rien si elle existe et on sort de la boucle foreach ?

de ce que je crois comprendre, si on enlève la break, la boucle va continuer avec le prochain cycle du foreach au lieu de sortir à la fin de la première image générée

d'ailleurs comme on a déjà affecté $image = $this->supplier->id; je pense qu'on peit potentiellement gagner un micoîème de pouillième de millisecondes avec file_exists(PS_SUPP_IMG_DIR. $image.

Mais peut être pas... je ne suis pas assez calé en objet pour savoir si il doit reparcourir l'objet ou si accerder à $îmage n'est pas mieux que d'acceder à $this->supplier->id, auquel cas, $this->supplier->id peut être plus parlant au niveau de lecture du code. et autrant de pas utiliser $image...

je ne suis pas assez fort en proga objet. (et puis il est tard :_)

edit : j'ai même l'impression qu'un continue ne servirait à rien puisqu'on est déjà la fin de la boucle

eolia

Si on a une image de base on boucle sur tous les formats de type "supplier".
Si l'un au moins est manquant, on ne se pose pas de question:

on tente de générer TOUS les formats.
soit c'est ok et les miniatures sont créées, soit non (cas qui ne devrait jamais arriver) et dans ce cas on affecte l'image par défaut dans la langue.
on stoppe la boucle (break), inutile de continuer à tester les formats.

eolia

D'ailleurs je vais rajouter le timestamp $img_time (comme pour les images catégories) car si on met à jour le fournisseur 1 avec une nouvelle image, celle-ci s'appellera toujours 1.jpg

Dans le thème:
<img src="{$img_sup_dir}{$supplier.image|escape:'html':'UTF-8'}-medium_default.jpg?rand={$img_time}" alt="" width="{$mediumSize.width}" height="{$mediumSize.height}" />