Regenerar problemas de imágenes de caché de catálogo

19

Estoy haciendo el proceso de migración de Magento 1.9.2.4 a Magento 2.1.6, después de completar la migración, muevo la carpeta multimedia de M1 a pub / media M2.

Ahora el problema es que algunas de las imágenes no se generan en la carpeta del catálogo / caché

Por ejemplo, las imágenes a continuación van a 404 no encontradas

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

Simplemente me gustó eliminar la carpeta de caché del catálogo y volver a cargar la página, pero aún así aparece una imagen rota.

Mi página tiene 50% de imágenes rotas

ingrese la descripción de la imagen aquí

puede compartir la solución para solucionar este problema?

Bilal Usean
fuente
Hola bilal, ¿puedes ayudarme y sugerir magento.stackexchange.com/questions/283277/…
Nagaraju K

Respuestas:

29

Debe intentar usar el comando de cambio de tamaño de imagen para generar previamente todos los cambios de tamaño necesarios.

php bin/magento catalog:image:resize

Este comando obtiene todos los tamaños de imágenes que se han definido en el tema XML y pregenera las imágenes en sus carpetas correctas.

También puede consultar la documentación del comando para obtener más información http://devdocs.magento.com/guides/v2.1/frontend-dev-guide/themes/theme-images.html

Alex Dinca
fuente
55
FYI: este comando tarda absolutamente una eternidad en ejecutarse en una tienda de cualquier tamaño. Vimos más de 17 horas en una carrera reciente. En otras ocasiones, necesitaba ejecutarse durante un fin de semana. Ver: github.com/magento/magento2/issues/8145
Leland
Tuve el mismo problema, ejecuté las imágenes de este cmd, pero después de vaciar la memoria caché, todas las imágenes se rompieron nuevamente y no hay imágenes en la carpeta de la memoria caché
imtiazau
1
Si utiliza php bin / magento catalog: image: redimensionar, le llevará más de 1 días, ¿y algún otro método mejor?
Soundararajan m
@Alex Dinca, ¿podría ayudarme en este magento.stackexchange.com/questions/283277/…
Nagaraju K
Recibo imágenes de Magento 2 de Magento 1 usando snipboard.io/JZ2bQR.jpg , ¿cómo resolver el problema de caché? @Alex
Gema
0

También tuve este problema e incluso la generación de imágenes de línea de comandos mencionada anteriormente no funcionó. Parece que Magento está almacenando en caché la información que crea la miniatura e incluso la limpieza estándar de caché de Magento (tanto en la línea de comando como en el panel de administración) no elimina esta información de la caché.

Eliminé todos los contenidos de los directorios de caché manualmente y me ayudó:

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

.. y así. Luego, las imágenes en miniatura se deben generar correctamente "a pedido" mientras se navega por el sitio.

A.Maksymiuk
fuente
0

Tuve exactamente el mismo problema pero con Magento 2.3.2

Para mí, las imágenes en miniatura del producto tenían la ruta de hash de caché incorrecta. Las imágenes de producto y categoría eran correctas, pero la URL de los pulgares era incorrecta y mostraba el marcador de posición de imagen estándar de Magento.

Estaba usando un tema personalizado.

Al usar SHH "php bin / magento catalog: images: resize" - ¿qué estaba pasando? Las imágenes se generaban utilizando el tema de Luma, etc / view.xml en lugar del archivo de tema personalizado etc / view.xml.

El problema. Al ver mi tema personalizado en el navegador que usa imágenes de diferentes tamaños para el tema de Luma, Magento no pudo encontrar las imágenes y muestra un error 404.

La solución.

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

Me llevó una semana descubrir cómo solucionar esto, pero ahora todo funciona bien.

colin008
fuente
0

Respuesta el 20 de noviembre de 2019:

Regenerar caché de imágenes por comando no es una solución factible para todos porque tomará mucho tiempo para algunos sitios web que tienen muchos productos. Además, enfrenté algunos problemas como si generamos una imagen de caché desde la CLI, funcionará. Cuando enjuagamos las imágenes del administrador o eliminamos la imagen en caché manualmente en ese momento, no generará una imagen de caché nuevamente al cargar la página, por lo que necesito ejecutar el comando regenerar una y otra vez. Según mi punto de vista, la mejor solución es generar caché de imágenes en la carga de la página.

Flujo predeterminado

El flujo predeterminado de Magento es cuando carga imágenes (medios), siempre pasará la solicitud a pub / get.php y comprobará si la imagen existe o no. Si no existe, generará una nueva imagen en caché. Si existe, devolverá ese camino. Por lo tanto, la imagen por defecto debería generar al cargar la página.

Podemos verificar este paso a través de la lógica en los archivos a continuación

pub/media/.htaccesspara el servidor apache

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

nginx.conf.samplepara el servidor nginx

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

¿Cómo verificar si esta lógica funciona o no?

Poner echo "test";exit;al inicio de pub / get.php y cargar cualquier URL de medios en caché, debe imprimir la prueba. De lo contrario, algo anda mal en la configuración de su servidor.

Para mí, cada vez que elimino el directorio de caché del catálogo (rm -rf pub / media / catalog / product / cache / *) después de eso, cuando cargamos la página, no generará una nueva imagen en caché y va a la página 404 no encontrada y También nunca llega a get.php . Luego noté que muchas de las carpetas tenían permisos incorrectos diferentes de 755 para carpetas y 644 para archivos. Después de establecer el permiso correcto, funciona bien.

Espero que te dé alguna idea.

Bilal Usean
fuente
Cualquier ayuda magento.stackexchange.com/q/296715/57334 gracias @Bilal Usean
zus