Régénérer les problèmes d'images de cache de catalogue

Je fais le processus de migration de Magento 1.9.2.4 vers Magento 2.1.6, une fois la migration terminée, je déplace le dossier multimédia de M1 vers pub / media M2.

Maintenant, le problème est que certaines images ne sont pas générées dans le dossier catalogue / cache

Par exemple, les images ci-dessous vont à 404 non trouvées

pub/media/catalog/product/cache/f9c7fbe9b524c081a3ccf800cbd963eb/m/s/msj006c-red_2.jpg
pub/media/catalog/product/cache/75eed2686e01eb22cb4050b2f40ddf97/m/s/msj006c-red_2.jpg
pub/media/catalog/product/cache/f9c7fbe9b524c081a3ccf800cbd963eb/m/s/msj006c-red_2.jpg

J'ai aimé simplement supprimer le dossier de cache du catalogue et charger à nouveau la page, mais elle va toujours à l'image cassée.

Ma page contient 50% d'images cassées

peut partager la solution de contournement pour résoudre ce problème?

Vous devriez essayer d'utiliser la commande image resize pour pré-générer tous les redimensionnements nécessaires.

php bin/magento catalog:image:resize

Cette commande obtient toutes les tailles d'images qui ont été définies dans le thème XML et prégénère les images dans leurs dossiers corrects.

Vous pouvez également consulter la documentation de la commande pour plus d'informations http://devdocs.magento.com/guides/v2.1/frontend-dev-guide/themes/theme-images.html

J'ai également eu ce problème et même la génération d'images de ligne de commande mentionnée ci-dessus n'a pas fonctionné. Il semble que Magento met en cache les informations qui créent la vignette et même le nettoyage du cache Magento standard (à la fois en ligne de commande ou dans le panneau d'administration) ne supprime pas ces informations du cache.

J'ai supprimé tous les contenus des répertoires de cache manuellement et cela a aidé:

rm -Rf var/cache/*
rm -Rf var/page_cache/*

.. etc. Ensuite, les images miniatures doivent être générées correctement "à la demande" lors de la navigation sur le site.

J'ai eu exactement le même problème mais avec Magento 2.3.2

Pour moi, ce sont les images miniatures des produits qui ont le mauvais chemin de hachage du cache. Les images des produits et des catégories étaient correctes, mais l'URL des pouces était incorrecte et montrait l'espace réservé pour l'image std Magento.

J'utilisais un thème personnalisé.

Lors de l'utilisation de SHH "catalogue php bin / magento: images: resize" - que se passait-il? Les images étaient générées à l'aide du thème Luma etc / view.xml au lieu du fichier de thème personnalisé etc / view.xml.

Le problème. Lors de l'affichage de mon thème personnalisé dans le navigateur qui utilise des images de tailles différentes du thème Luma, Magento n'a pas pu trouver les images et affiche une erreur 404.

Le correctif.

Replace Luma themes etc/view.xml with my custom theme etc/view.xml
Using SHH run "php bin/magento catalog:images:resize

J'ai mis une semaine à découvrir comment résoudre ce problème, mais tout fonctionne bien maintenant.

Veuillez voir votre configuration dans le thème que vous utilisez et assurez-vous que la configuration de votre magasin source est la même que celle de votre cible. Vous pouvez vous y référer: https://devdocs.magento.com/guides/v2.3/frontend-dev-guide/themes/theme-images.html

Exécutez ensuite:

catalogue php bin / magento: images: redimensionner

Faites-moi savoir si cela aide!

Réponse le 20 novembre 2019:

Régénérer le cache d'image par commande n'est pas une solution réalisable pour tous car cela prendra beaucoup de temps pour certains sites Web qui ont beaucoup de produits. De plus, j'ai rencontré des problèmes comme Si nous générons une image de cache à partir de CLI, cela fonctionnera. Lorsque nous vidons les images de l'administrateur ou supprimons manuellement l'image mise en cache à ce moment-là, cela ne génère pas à nouveau une image de cache lors du chargement de la page, j'ai donc besoin d'exécuter la commande régénérer encore et encore. Selon mon point de vue, la meilleure solution est de générer un cache d'image au chargement de la page.

Flux par défaut

Le flux Magento par défaut est chaque fois qu'il charge une image (média), il passera toujours par la demande à pub / get.php et vérifiera si l'image existe ou non. S'il n'existe pas, il générera une nouvelle image en cache. S'il existe, il retournera ce chemin. Donc, par défaut, l'image devrait générer au chargement de la page.

Nous pouvons vérifier cette logique de transmission dans les fichiers ci-dessous

pub/media/.htaccesspour le serveur apache

RewriteRule .* ../get.php [L]
.............................
.............................

nginx.conf.samplepour le serveur nginx

location /media/ {
    try_files $uri $uri/ /get.php$is_args$args;
    .......................................
    .......................................

Comment vérifier que cette logique fonctionne ou non?

Mettez echo "test";exit;au début de pub / get.php et chargez n'importe quelle URL de média en cache, il devrait imprimer le test. Sinon, quelque chose ne va pas dans la configuration de votre serveur.

Pour moi, chaque fois que j'ai supprimé le répertoire de cache du catalogue (rm -rf pub / media / catalogue / product / cache / *) après cela, lorsque nous chargeons la page, il ne générera pas une nouvelle image en cache et il ira à la page 404 non trouvée et il n'atteint jamais non plus get.php . J'ai ensuite remarqué que de nombreux dossiers avaient des autorisations incorrectes différentes de 755 pour les dossiers et 644 pour les fichiers. Après avoir défini la bonne autorisation, cela fonctionne bien.

J'espère que ça donne une idée.