Ponownie wygeneruj problemy z obrazkami z pamięci podręcznej katalogu

Robię proces migracji z Magento 1.9.2.4 do Magento 2.1.6, po zakończeniu migracji przenoszę folder multimediów M1 do pub / media M2.

Teraz problem polega na tym, że niektóre obrazy nie generują się w folderze katalogu / pamięci podręcznej

Na przykład poniżej obrazy trafiają do 404 nie znaleziono

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

Chciałem po prostu usunąć folder pamięci podręcznej katalogu i ponownie załadować stronę, ale nadal przechodzi ona do uszkodzonego obrazu.

Moja strona zawiera 50% uszkodzonych obrazów

może udostępnić obejście, aby rozwiązać ten problem?

Powinieneś spróbować użyć polecenia zmiany rozmiaru obrazu, aby wstępnie wygenerować wszystkie niezbędne zmiany rozmiaru.

php bin/magento catalog:image:resize

To polecenie pobiera wszystkie rozmiary obrazów, które zostały zdefiniowane w motywie XML i wstępnie generuje obrazy w odpowiednich folderach.

Możesz również sprawdzić dokumentację poleceń, aby uzyskać więcej informacji http://devdocs.magento.com/guides/v2.1/frontend-dev-guide/themes/theme-images.html

Miałem również ten problem i nawet wspomniane powyżej generowanie obrazów z wiersza poleceń nie działało. Wygląda na to, że Magento buforuje informacje o utworzeniu miniatury, a nawet standardowe czyszczenie pamięci podręcznej Magento (zarówno z wiersza poleceń, jak i panelu administracyjnego) nie usuwa tych informacji z pamięci podręcznej.

Usunąłem ręcznie całą zawartość katalogów pamięci podręcznej, co pomogło:

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

.. i tak dalej. Następnie miniatury obrazów powinny prawidłowo generować „na żądanie” podczas przeglądania witryny.

Miałem ten sam problem, ale z Magento 2.3.2

Dla mnie to miniatury produktów miały niewłaściwą ścieżkę pamięci podręcznej. Obrazy produktów i kategorii były poprawne, ale URL kciuka był niepoprawny i wyświetlał symbol zastępczy standardowego obrazu Magento.

Korzystałem z niestandardowego motywu.

Podczas korzystania z SHH „php bin / magento catalog: images: resize” - co się działo? Obrazy były generowane przy użyciu motywu Luma etc / view.xml zamiast niestandardowego pliku etc / view.xml.

Problem. Podczas przeglądania mojego niestandardowego motywu w przeglądarce, która używa obrazów o innym rozmiarze niż motyw Luma, Magento nie mógł znaleźć obrazów i wyświetla błąd 404.

Poprawka

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

Zajęło mi tydzień, aby dowiedzieć się, jak to naprawić, ale teraz wszystko działa dobrze.

Sprawdź swoją konfigurację w używanym motywie i upewnij się, że konfiguracja w sklepie źródłowym jest taka sama jak w twoim celu. Możesz odnieść się do tego: https://devdocs.magento.com/guides/v2.3/frontend-dev-guide/themes/theme-images.html

Następnie uruchomić:

katalog php bin / magento: obrazy: zmiana rozmiaru

Daj mi znać, jeśli to pomoże!

Odpowiedź 20 listopada 2019 r .:

Ponowne generowanie pamięci podręcznej obrazów za pomocą polecenia nie jest realnym rozwiązaniem dla wszystkich, ponieważ zajmie to dużo czasu dla niektórych witryn internetowych z dużą ilością produktów. Ponadto napotkałem kilka problemów, takich jak generowanie obrazu pamięci podręcznej z interfejsu CLI, to zadziała. Kiedy opróżniliśmy obrazy od administratora lub ręcznie usunęliśmy obraz z pamięci podręcznej w tym czasie, nie będzie on ponownie generować obrazu pamięci podręcznej przy ładowaniu strony, więc muszę ponownie uruchamiać polecenie regeneracji. Z mojego punktu widzenia najlepszym rozwiązaniem jest wygenerowanie pamięci podręcznej obrazu przy ładowaniu strony.

Domyślny przepływ

Domyślny przepływ Magento odbywa się za każdym razem, gdy ładuje obraz (media), zawsze przechodzi przez żądanie do pub / get.php i sprawdza, czy obraz istnieje, czy nie. Jeśli nie istnieje, wygeneruje nowy buforowany obraz. Jeśli istnieje, zwróci tę ścieżkę. Tak więc domyślnie obraz powinien generować się przy ładowaniu strony.

Możemy sprawdzić to przejście przez logikę w poniższych plikach

pub/media/.htaccessdla serwera Apache

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

nginx.conf.sampledla serwera nginx

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

Jak sprawdzić, czy ta logika działa, czy nie?

Wpisz echo "test";exit;początek pub / get.php i załaduj dowolny adres URL mediów w pamięci podręcznej, powinien wydrukować test. W przeciwnym razie wystąpi błąd w konfiguracji serwera.

Dla mnie za każdym razem, gdy usuwam katalog pamięci podręcznej katalogu (rm -rf pub / media / catalog / product / cache / *) po tym, gdy ładujemy stronę, nie będzie generować nowego obrazu w pamięci podręcznej, a strona 404 nie zostanie znaleziona i także nigdy nie osiąga get.php . Następnie zauważyłem, że wiele folderów ma niepoprawne uprawnienia inne niż 755 dla folderów i 644 dla plików. Po ustawieniu odpowiedniego uprawnienia działa dobrze.

Mam nadzieję, że daje to pewien pomysł.