controlleur fournisseurs.

herve_02

Je suis un tout newbie au code de phenix, mais je dois faire des modifications pour faire tomber en marche comme "on" (ah ah) veut (on a tous un chef au dessus). L'objectif avoué étant d'avoir les photos des fournisseurs (qui sont des auteurs chez nous) Nous utilisons un dérivé du thème default-bootstrap car, même si cela demande plus de travail qu'en trouver un qui ressemble plus à ce que nous voulons, au moins nous sommes le plus proche possible du main stream.
donc pour revenir à nos moutonnssss.

Je me suis penché sur le controller front SupplierController qui regarde s'il y a des images

$row['image'] = (!file_exists(_PS_SUPP_IMG_DIR_.'/'.$row['id_supplier'].'-'.ImageType::getFormatedName('medium').'.jpg')) ?
                   $this->context->language->iso_code.'-default' :
                   $row['id_supplier'];

La question est pourquoi tester sur 'medium' alors que naturellement si une image existe il y a obligatoirement $id_supplier.'.jpg' ret maintenant ( ???) $id_supplier.'.png' pour les transparence - ceci dit c'est eut être que sur les produits la transparence.

Alors peut être y-a-t-il une raison à cela ?

en renvoyant juste l'id_supplier (ce qui est fait) cela permet au thème de choisir l'image qui veut être affichée et qui est donc core-agnostique.
j'ai téléchargé un zip vanilla pour vérifier que ce n'était pas moi qui avait fait cette modif il y a longtemps pour faire tomber en marche un truc que je ne comprenais pas.

Ce code sert à suppler-list.tpl (assignAll) mais je vais le "dupliquer" dans assignOne pour avoir l'image dans la page du fournisseur.

Et c e n'est pas idiot non plus cela permettrait à un fabricant ou petit artisan de montrer dans quels boutiques (avec une photo) ou ses produits sont vendus, les boutiques étant du coup attachées aux produits et pas à l'artisan. proposant différentes filières : des produits vendus là et pas ailleurs et d'autre vendus ailleurs et pas là.
Il suffit juste de traduire supplier différemment.

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}" />