Récemment
-
Images produit qui disparaissent
Bugs & Améliorations30 -
devcustom ?
PhenixSuite5 -
Mode profiling
Bugs & Améliorations1 -
Urls bizarres dans la console search
PhenixSuite12 -
Erreurs 410 dans BO
PhenixSuite3 -
la classe search
Bugs & Améliorations2 -
Probleme depuis MAJ phenix 1.6.2.36
PhenixSuite8 -
[resolu] Le module mondial relay 3.4.5
Bugs & Améliorations1 -
controlleur fournisseurs.
Bugs & Améliorations11 -
J'en profite (la fougue de la jeunesse) (ah ah ah)
Bugs & Améliorations5 -
Bon dernier du jour mais cela me turlupine classe search
Bugs & Améliorations4 -
se connecter comme un client idntifié
Bugs & Améliorations1 -
la bonne blague
Discussion générale2 -
Passage de la 16.1.9 a la PhenixSuite 1.6.2.36
Bugs & Améliorations8 -
Echec de l'installation de Creative Elements
Bugs & Améliorations3 -
[Résolu] Modification données client dans l'admin
PhenixSuite10 -
googletagmanager
PhenixSuite2 -
2 téléphones obligatoires
PhenixSuite11 -
Liens qui disparaissent
PhenixSuite5 -
Smart cache JS et Iphone
PhenixSuite1
Images produit qui disparaissent
-
Pour ma part, oui, je les vois bien après les avoir ajoutées. C'est après qu'elles "disparaissent" et aucune trace dans le ftp. Ce n'est même pas systématique.
-
Vous n'avez pas 2 onglets ouverts sur la même page produit ? Un sur lequel vous avez enregistré l'image et pas sur l'autre par exemple et ensuite vous modifiez l'autre (texte ou prix par exemple) et vous l'enregistrez mais lui n'a pas connaissance de l'image.
-
ah pas bête ça ! je vais y faire attention pour voir si c'est le cas, ce qui ne serait pas étonnant. Merci pour cette piste !
Ah, je suis considérée comme nouvel utilisateur, je dois attendre avant de pouvoir envoyer cette réponse !
-
bonjour Eolia,
Le souci est toujours là. Le matin, on constate que des images ont disparu alors qu'il n'y a eu aucune intervention sur le site.
Aujourd'hui, cette page n'a quasiment plus aucune image. Les dossiers correspondants dans le ftp se sont évaporés. J'ai vérifié dans la bdd si ces produits avaient été mis à jour récemment, mais le premier testé ne l'a été qu'en janvier de cette année. Les lignes correspondant à ces produits dans la table image sont toujours là.
Sur le clone servant aux tests, en mode maintenance, à priori aucune image n'a disparu, mais on n'y a plus touché depuis un moment.
Tout à fait par hasard, cela pourrait-il être lié à la suppression des images orphelines ? La fonctionnalité n'est pas activée et je ne l'ai jamais utilisée mais on ne sait jamais ...
-
Bonjour,
Non la fonctionnalité de nettoyage des orphelines ne s'exécute que si on la met sur OUI et uniquement une fois (ensuite le paramètre repasse à non).
Ne sont supprimées que les images qui ne sont liées à aucun produit dans la table ps_image.
Le produit de la page concernée a été modifié récemment ? (on peut le voir dans les logs Presta)
-
Non, j'ai juste vérifié le premier affiché sur la page dont j'ai donné le lien et ai vérifié dans la bdd la date_upd dans la table products. A priori, sa dernière modif date de janvier de cette année.
-
Je viens de re-scanner le code et les seuls endroits où les images sont supprimées (unlink()) sont dans la classe Image.php mais il faut appeler la fonction deleteImage(), il n'y a rien d'automatique.
Pas d'imports, de module de nettoyage ou autre parce que là je ne vois vraiment pas :(
-
Ben non, pas d'imports, les produits sont ajoutés manuellement via le BO. Pas de module de nettoyage non plus.
Je vous joins la liste des modules actifs. Certains sont de mon cru, mais aucun n'agit sur les images produits.
C'est vraiment curieux car le problème est survenu il n'y a pas longtemps. On est resté longtemps sur le site de dev (bp de modif dans les textes à faire) sans aucun souci. Cela touche des produits sur lesquels on n'est pas intervenus depuis un moment comme des produits mis à jour ou des nouveaux produits. C'est aléatoire. C'est la surprise du matin ...! J'ai vérifié le module créé pour ajouter le webp aux images des catégories, mais il ne cible que celles-ci et il n'y a pas de deleteImage.
Au début, cela ne semblait concerner que quelques produits. Là (ou est-ce parce cette fois ça touche une page entière) c'est quasi 30 produits.
-
Bonjour, aujourd'hui 30 images ont "disparu".
Alors je cherche.- J'ai vu que la régénération des images était automatique. Utilise-t-elle la même procédure que celle de Prestashop ? (qui génère des erreurs 500 quand il y a beaucoup d'images).
Si oui, j'ai peut-être alors une explication sur le nombre de pannes avec erreur 500 - Si elle est automatique et que le bouton "Supprimer les anciennes images" est activé, alors à chaque fois ces images sont supprimées pour être régénérées.
Sauf que, à première vue, si des produits sont désactivés, les déclinaisons d'images sont supprimées et pas régénérées (home, cart, etc). Mais l'image de base est gardée. Ex 160.jpg
=> je n'ai pas encore tout vérifié, mais les images qui disparaissent sont, à priori, toutes dans des sous-dossiers d'images de produits désactivés.
Ex : le produit 946 a une image id 1608, le 947 image id 1609, etc
Dans le dossier 1>0>6 j'ai l'image 160.jpg (produit désactivé) mais je n'ai plus aucun sous-dossier
J'ai désactivé la suppression des images dans la régénération. Il ne m'avait jamais semblé que l'état de ce bouton était pris en compte dans Prestashop.
Donc, est-il possible que le processus de Phenix fasse comme la régénération manuelle de PS, avec prise en compte de l'état du bouton ? Et en provoquant autant d'erreurs 500 ? (au point qu'en général, sur PS, j'installe un module pour le faire, sans surcharge serveur)Merci d'avance
- J'ai vu que la régénération des images était automatique. Utilise-t-elle la même procédure que celle de Prestashop ? (qui génère des erreurs 500 quand il y a beaucoup d'images).
-
Je confirme mon doute. J'ai testé sur le dev, à 2 reprises.
Dans la bdd j'ai vu des images "soeurs"
img id = 130 -> prod id = 166
img id = 1301 - prod id = 840
img id = 1302 - prod id = 841
Donc j'ai ajouté une image au prod id 166.
-> tout est ok
J'ai alors supprimé l'ancienne image du prod 166 (img id 130)
-> les produits 840 et 841 ont perdu leurs images, les dossiers 1>3>0>1 et 1>3>0>2 ont été effacés immédiatement.Je ne sais pas si il y a un lien mais j'ai testé ceci aussi sur le site de dev :
img id 120 prod id 100.
Ajout d'une image que je mets en couv
-> dans le ftp la 120.jpg a perdu ses vignettes (home, cart, etc).
Mais les dossiers 120x sont (encore) là.Sur le site de prod, hier, il y avait aussi des images "seules", elles semblent avoir toutes disparu aujourd'hui. Et, à priori, personne ne les a supprimées dans les fiches produit. Peut-être un script qui les considérait comme "orphelines" parce que sans vignettes ?
voilà ...
peut-être cela peut-il donner une piste ? un script trop gourmand ?
Et comment savoir à quel moment la régénération automatique se fait ? Pour savoir si cela concorde avec les nombreuses erreurs 500 ?Merci d'avance !
-
Je vais regarder vos pistes.
Concernant la regénération:- Plus d'erreur 500 car on ne les regénère plus, c'est en direct au 1er appel en FO ou BO.
- Si vous cochez "Effacer les images précédentes" cela supprime uniquement les miniatures mais jamais l'image d'origine
-
Merci Eolia. A première vue, avec ChatGpt, nous avons réussi à faire un override de la class Image.php et du controller admin AdminImagesController.php. Testé sur 2 copies du prod, la dernière version semble être ok.
Voici le code de AdminImagesController.php<?php /** * Override anti-cascade pour la suppression/régénération des vignettes * Phenix/PS 1.6.x – DEV */ class AdminImagesController extends AdminImagesControllerCore { /** * SAFE: supprime uniquement les tailles explicites, jamais l’original id.jpg, * et n'exécute pas de nettoyage récursif global (pas de "cascade" sur les soeurs). */ protected function _deleteOldImages($dir, $type, $product = false) { // TRACE facultative (décommente pour vérifier l’override) // @error_log("[IMG] override _deleteOldImages CALLED in ".__FILE__."\n", 3, _PS_ROOT_DIR_."/var/log/img_trace.log"); if (!is_dir($dir)) { return true; } // OK : purge du /img/tmp uniquement Tools::deleteDirectory(_PS_TMP_IMG_DIR_, false); // Liste blanche stricte des tailles if (!is_array($type) || empty($type)) { return true; } $allowed = array(); foreach ($type as $t) { if (!empty($t['name'])) { $allowed[] = $t['name']; } } if (empty($allowed)) { return true; } $entries = scandir($dir); if (!is_array($entries)) { return true; } foreach ($entries as $d) { // Ne JAMAIS toucher à l'original (ex: 130.jpg) if (preg_match('/^[0-9]+\.jpe?g$/i', $d)) { continue; } // Supprimer uniquement : // - id[-id_product]-<type>.jpg|webp // - <lang>-default-<type>.jpg|webp foreach ($allowed as $name) { $reBase = '/^[0-9]+-'.($product ? '[0-9]+-' : '').preg_quote($name,'/').'\.(?:jpe?g|webp)$/i'; $reLang = '/^[a-z]{2}-default-'.preg_quote($name,'/').'\.(?:jpe?g|webp)$/i'; if (preg_match($reBase, $d) || preg_match($reLang, $d)) { $full = $dir.$d; if (file_exists($full)) { @unlink($full); } break; } } } // pas de nettoyage récursif global (source de suppression en cascade) // if ($product) { $this->cleanAllImages(_PS_PROD_IMG_DIR_); } return true; } /** * Par sécurité, si du code legacy appelle encore cleanAllImages(), * on le rend inoffensif (pas de suppression récursive). */ public function cleanAllImages($path) { // TRACE facultative // @error_log("[IMG] cleanAllImages bypassed in ".__FILE__."\n", 3, _PS_ROOT_DIR_."/var/log/img_trace.log"); return true; } }
et de Image.php
<?php /** * Override SAFE de la classe Image (suppression non-destructive) * - Ne touche jamais à l’original id.jpg * - Ne supprime que les tailles de l’image courante * - Pas de nettoyage récursif / pas de prune des dossiers parents */ class Image extends ImageCore { /** * Journalise l’appel puis délègue au parent. * Le parent appellera $this->deleteImage(), qui est overridée ci-dessous. */ public function delete() { @file_put_contents( _PS_ROOT_DIR_.'/var/log/img_trace.log', date('c')." Image::delete id_image={$this->id} id_product={$this->id_product}\n", FILE_APPEND ); // On laisse le parent gérer la partie BDD (ps_image*, position, cover…) return parent::delete(); } /** * Suppression des fichiers sur disque (override SAFE) * $force_delete est ignoré volontairement pour NE PAS supprimer l’original. */ public function deleteImage($force_delete = false) { // Chemin de base sans extension, ex: /img/p/1/3/0/0/1300 $basePath = $this->getPathForCreation(); $dir = dirname($basePath).'/'; // 1) SUPPRIMER l’original et ses variantes (jpg, png, webp) $exts = array('jpg','png','webp'); foreach ($exts as $ext) { $orig = $basePath.'.'.$ext; if (file_exists($orig)) { @unlink($orig); @file_put_contents( _PS_ROOT_DIR_.'/var/log/img_trace.log', date('c')." unlink original: ".$orig."\n", FILE_APPEND ); } } // 2) Supprimer UNIQUEMENT les déclinaisons de CETTE image $types = ImageType::getImagesTypes('products', false); $exts = array('jpg','webp'); // on couvre les 2 familles foreach ($types as $t) { $name = stripslashes($t['name']); foreach ($exts as $ext) { $file = $basePath.'-'.$name.'.'.$ext; if (file_exists($file)) { @unlink($file); @file_put_contents( _PS_ROOT_DIR_.'/var/log/img_trace.log', date('c')." unlink variant: ".$file."\n", FILE_APPEND ); } // variante 2x si jamais utilisée $file2x = $basePath.'-'.$name.'2x'.'.'.$ext; if (file_exists($file2x)) { @unlink($file2x); @file_put_contents( _PS_ROOT_DIR_.'/var/log/img_trace.log', date('c')." unlink variant2x: ".$file2x."\n", FILE_APPEND ); } } } // 3) NE PAS remonter dans l’arbo, NE PAS pruner les dossiers parents // (donc pas de rmdir(), pas de cleanAllImages()) // On considère l’opération disque OK même si certaines variantes n’existaient pas. return true; } }
Je ne suis hélas pas dév PHP, je peux y apporter des changements, mais pour créer des overrides, j'ai préféré me faire aider. Car pour la gestion du site, cela commençait à devenir vraiment compliqué, ces disparitions d'images. Pour les anciennes, je pouvais les récupérer du clone d'origine. Mais pour les nouvelles, on est obligé de les renvoyer. Avec, en plus, un souci au niveau de la bdd vu que les anciennes assos img/prod n'étaient pas supprimées.
Pour les erreurs 500, si elles ne peuvent être liées à un script auto de régénération, alors d'où peuvent-elles venir ? J'attends un avis de spécialiste demain chez O2Switch car ni eux, ni moi, n'arrivons à trouver une piste :-(
-
Par contre, est-ce normal que, d'office, le bouton "Effacer les anciennes images" reste actif ? J'ai beau le mettre sur non, quand je reviens sur la page il est de nouveau actif.
-
Le problème est sur la fonction Tools::cleanDirectory($this->image_dir.$this->getImgFolder()); rien d'autre et c'est en cours de résolution.
Pour le bouton "Effacer les images" (actif par défaut) si celui-ci n'est pas actif il ne se passera rien pour les produits lorsque vous cliquerez sur "Regénérer", seules les miniatures manquantes seront générées lorsqu'elles seront appelées.
-
commentez la ligne 665 de Image.php ( //Tools::cleanDirectory($this->image_dir.$this->getImgFolder()); ) en attendant le patch. Les répertoires vides ne seront pas nettoyés mais ce n'est pas grave pour l'instant.
-
Merci Eolia,
J'attends donc la résolution :-) en attendant l'override évite de nouvelles disparitions.
Me trompe-je ou, d'habitude, il n'est pas activé par défaut ? Justement pour éviter de tout régénérer si on oublie de le désactiver pour quelques vignettes manquantes ?
Et est-ce que le script automatique prend en compte cela et donc régénèrerait toutes les vignettes quand on ajoute une image ? Car les erreurs 500 ont quand même l'air d'être assez reliées aux moments où on ajoute des images ...
-
Je me répète mais Phenix ne regénère jamais toutes les miniatures (ce qui provoquait souvent des erreurs 500).
Si vous cliquez sur regénérer en ayant coché "supprimer les images" seules les miniatures sont supprimées. L'image de base jpg reste seule.Lorsque vous naviguerez sur le FO les images manquantes seront regénérées à la volée pour le ou les produits en cours de visualisation.
-
@eolia merci, je vais tester ça sur le dev
-
@eolia ok merci, je voulais juste m'en assurer car je suis toutes les pistes qui pourraient m'expliquer la fréquence des erreurs 500, avec perte de connexion à la bdd. Les logs sont absolument silencieux là-dessus...
-
Function à remplacer dans Image.php:
public function deleteImage($force_delete = false) { if(!$this->id) { return false; } $parent_dir = $this->image_dir.$this->getImgFolder(); if(Configuration::get('PS_LEGACY_IMAGES')) { $files_to_delete = array(); // Delete base image if(file_exists($this->image_dir.$this->getExistingImgPath().'.'.$this->image_format)) { @unlink($this->image_dir.$this->getExistingImgPath().'.'.$this->image_format); } // Delete auto-generated images $image_types = ImageType::getImagesTypes(); foreach($image_types as $image_type) { $files_to_delete[] = $this->image_dir.$this->getExistingImgPath().'-'.$image_type['name'].'.'.$this->image_format; $files_to_delete[] = $this->image_dir.$this->getExistingImgPath().'-'.$image_type['name'].'.webp'; if(Configuration::get('WATERMARK_HASH')) { $files_to_delete[] = $this->image_dir.$this->getExistingImgPath().'-'.$image_type['name'].'-'.Configuration::get('WATERMARK_HASH').'.'.$this->image_format; $files_to_delete[] = $this->image_dir.$this->getExistingImgPath().'-'.$image_type['name'].'-'.Configuration::get('WATERMARK_HASH').'.webp'; } } // Delete watermark image $files_to_delete[] = $this->image_dir.$this->getExistingImgPath().'-watermark.'.$this->image_format; $files_to_delete[] = $this->image_dir.$this->getExistingImgPath().'-watermark.webp'; // Delete index.php $files_to_delete[] = $parent_dir.'index.php'; foreach ($files_to_delete as $file) { if (file_exists($file) && !@unlink($file)) { return false; } } } else { if(is_dir($parent_dir)) { $files = glob($parent_dir.'*'); foreach($files as $file) { if(is_file($file)) { unlink($file); } } } } self::deleteTempImages($this->id_product); // Delete the image folder if empty if(is_dir($parent_dir)) { $delete_folder = true; foreach(scandir($parent_dir) as $file) { if($file != '.' && $file != '..') { $delete_folder = false; file_put_contents($parent_dir.'index.php', Tools::getDefaultIndexContent($path)); break; } } } if(isset($delete_folder) && $delete_folder) { @rmdir($this->image_dir.$this->getImgFolder()); } return true; }