Gdy obrazy prestashop nie wyświetlają się na stronach produktów, kategoriach ani na stronie głównej, klienci widzą zamiast katalogu uszkodzone ikony. Pliki zazwyczaj nadal znajdują się na serwerze – PrestaShop po prostu nie może udostępnić właściwej ścieżki, rozmiaru lub reguły przepisywania. Ten przewodnik opisuje szybki krok diagnostyczny, sposób przechowywania obrazów, typowe przyczyny i rozwiązania, które rozwiązują większość przypadków bez pełnej reinstalacji.

Diagnostyka na początku (dwie minuty)
Zanim zacznie się zmieniać uprawnienia lub regenerować wszystko od nowa, warto ustalić, jak dokładnie obrazy nie wyświetlają się w przeglądarce:
- Otwórz sam adres URL obrazu – kliknij prawym przyciskiem uszkodzony obraz → Otwórz obraz w nowej karcie. Sprawdź status: 404 (brak pliku lub reguły przepisywania), 403 (uprawnienia / reguły hotlink), albo obraz się ładuje, a strona nadal wygląda na uszkodzoną (motyw lub moduł lazy-load).
- Sprawdź konsolę przeglądarki – ostrzeżenia o mixed content oznaczają, że strona działa pod
https://, asrcnadal wskazujehttp://. - Porównaj Back Office ze sklepem – jeśli formularz produktu pokazuje zdjęcie, a front office jest pusty, zwykle winne są miniatury, przepisywanie Friendly URL lub domena sklepu. Jeśli obie strony są puste, szuka się brakującego pliku na dysku lub wiersza w bazie bez odpowiadającego pliku.
- Przełącz Friendly URL raz – Parametry sklepu → Ruch i SEO. Jeśli obrazy pojawiają się tylko przy wyłączonym Friendly URL, naprawia się
.htaccess/ reguły Nginx dla obrazów, zanim zregeneruje się cały katalog.
PrestaShop przechowuje oryginały i wygenerowane rozmiary w folderze /img/ w katalogu głównym sklepu. Wiedza, który katalog zawiera jakie zasoby, oszczędza czas przy szukaniu brakującego pliku:
/img/p/– obrazy produktów. Przesłane pliki są rozdzielane na zagnieżdżone foldery (na przykład/img/p/1/2/12.jpgdla produktu o ID 12). PrestaShop tworzy też warianty miniatur dla siatek list, koszyków i strony produktu./img/c/– obrazy kategorii z własnymi rozmiarami miniatur./img/cms/– obrazy używane na stronach CMS. Zwykle omijają one pipeline miniatur produktowych, więc regeneracja miniatur produktów nie naprawi uszkodzonej ścieżki mediów CMS.
Jeśli adres URL obrazu w sklepie zwraca 404, a plik istnieje na dysku, sprawdza się uprawnienia, przepisywanie .htaccess / Nginx oraz typy miniatur, zanim prześle się ponownie każde zdjęcie. Problemy z Friendly URL często idą w parze z błędami ścieżek obrazów – warto zajrzeć do artykułu o rozwiązywaniu problemów z przepisywaniem adresów URL SEO w PrestaShop, gdy jednocześnie psują się linki produktów i adresy URL mediów.
Typowe przyczyny, gdy obrazy prestashop się nie wyświetlają
- Nieprawidłowe uprawnienia plików – serwer WWW nie może odczytać (ani zapisać) plików w
/img/. - Uszkodzony lub niekompletny
.htaccess– szczególnie po przeniesieniu, przejściu na HTTPS lub ręcznej edycji. - Nieprawidłowa domena sklepu, domena SSL lub base URI – po migracji adresy URL obrazów nadal wskazują stary host lub folder.
- Ustawienia typów obrazów – brakujące lub zerowe formaty w Wygląd → Ustawienia obrazów.
- Przerwana regeneracja miniatur – część rozmiarów nigdy nie została zapisana.
- Brak biblioteki obrazów PHP – GD lub Imagick nie są zainstalowane, więc regeneracja nie może tworzyć plików.
- Moduły związane z obrazami – lazy load, CDN, znak wodny lub moduły optymalizacji, które zawodzą.
- Nieaktualna pamięć podręczna – cache PrestaShop, moduł cache lub przeglądarka nadal serwują stare adresy URL.
- Niezgodność po aktualizacji lub na poziomie systemu plików – motyw oczekuje nowych typów obrazów albo układ legacy vs nowy
/img/p/po przeniesieniu starego sklepu. - Luki w przepisywaniu Nginx – reguły w stylu Apache z PrestaShop nie działają; trasy obrazów wymagają konfiguracji serwera.
Mixed content po wymuszeniu HTTPS to kolejna częsta przyczyna: strona ładuje się przez https://, a tagi obrazów nadal wskazują http://, więc nowoczesne przeglądarki je blokują. Należy potwierdzić, że adresy sklepu i mediów używają HTTPS w Parametry sklepu → Ruch i SEO (oraz w każdym module CDN).

Jak naprawić obrazy prestashop, które się nie wyświetlają
- Napraw uprawnienia w
/img/– przez FTP lub menedżer plików hosta katalogi zwykle mają 755, a pliki 644. Warto spróbować 775 / 664 tylko wtedy, gdy host wymaga zapisu grupowego. Unika się 777 / 666 poza krótkim testem, a potem blokuje uprawnienia z powrotem. Użytkownik WWW musi też móc zapisywać w tym miejscu, inaczej regeneracja miniatur zakończy się cicho niepowodzeniem. - Popraw adres URL sklepu po przeniesieniu – w Parametry sklepu → Ruch i SEO ustawia się Domenę sklepu, Domenę SSL i Base URI na działający host (w tym podkatalog, jeśli sklep nie jest w korzeniu domeny). Zapis powoduje przepisanie
.htaccessprzez PrestaShop. Złe domeny to główna przyczyna problemów z obrazami tuż po migracji. Jeśli atrybutysrcobrazów nadal pokazują stary host, czyści się cache i sprawdza ustawienia CDN. - Regeneruj
.htaccess– na tym samym ekranie SEO i adresów URL zapisuje się ustawienia Friendly URL, aby odbudować główny.htaccess. Następnie sprawdza się adres URL obrazu produktu w prywatnym oknie przeglądarki. - Potwierdź GD lub Imagick – PrestaShop potrzebuje rozszerzenia obrazów PHP do zmiany rozmiaru przesłanych plików. Na serwerze sprawdza się, czy PHP GD (lub Imagick) jest włączone dla tej samej wersji PHP, której używa sklep. Bez tego Wygląd → Ustawienia obrazów może wyglądać poprawnie, a nowe miniatury nie pojawią się na dysku.
- Przejrzyj typy obrazów i zregeneruj miniatury – przechodzi się do Wygląd → Ustawienia obrazów. Potwierdza się, że każdy format używany przez motyw ma sensowną szerokość/wysokość. Uruchamia się Regeneruj miniatury. Oficjalne notatki po aktualizacji też to podkreślają, gdy obrazy znikają po skoku wersji – patrz checklista po aktualizacji PrestaShop. Ten krok sam w sobie naprawia dużą część przypadków „zepsutych miniatur”.
- Wznów zablokowaną regenerację – jeśli pasek postępu zatrzymał się w połowie, wysyła się formularz ponownie z odznaczoną opcją Usuń poprzednie obrazy, aby PrestaShop kontynuował zamiast kasować gotowe rozmiary i zaczynać od zera. W dużych katalogach regeneruje się jeden typ obrazu na raz, aby timeout nie ukrył miejsca awarii.
- Ścieżki legacy vs nowe dla obrazów produktów – sklepy przeniesione z bardzo starych wersji PrestaShop czasem nadal trzymają pliki w płaskim układzie, podczas gdy obecny sklep oczekuje zagnieżdżonych folderów w
/img/p/(lub odwrotnie). W Ustawieniach obrazów używa się opcji przeniesienia obrazów do nowego systemu plików, gdy pasuje to do danych – potem regeneruje miniatury. Nie przełącza się tej opcji na ślepo na żywym sklepie bez kopii zapasowej. - Izoluj moduły obrazów – wyłącza się ostatnie moduły lazy-load, WebP, CDN lub watermark, czyści cache i testuje ponownie. Włącza się je pojedynczo, aby znaleźć winowajcę.
- Wyczyść cache – Zaawansowane parametry → Wydajność → wyczyść cache. Opróżnia się też moduł cache/CDN. Odświeża się na twardo lub czyści cache przeglądarki, aby nie patrzeć na stary uszkodzony adres URL.
- Po aktualizacji – czyści się cache, regeneruje miniatury i potwierdza, że wymagane przez aktywny motyw typy obrazów nadal istnieją w Ustawieniach obrazów. Aktualizacja motywu, która dodaje nowy format, pokaże puste miejsca, dopóki ten typ nie zostanie wygenerowany.
- Nginx – PrestaShop nie zapisze za Ciebie konfiguracji Nginx. Prosi się hosta (lub administratora) o poprawne mapowanie reguł obrazów i legacy; porównuje z sprawdzonym fragmentem Nginx dla PrestaShop w danej wersji głównej.
Jeśli sam Back Office pokazuje biały ekran podczas tych kroków, traktuje się to najpierw jako osobny problem PHP/logów błędów – zaczyna się od przewodnika po białym ekranie śmierci w PrestaShop, a potem wraca do regeneracji obrazów.
Jeśli po uprawnieniach, sprawdzeniu domeny/adresów URL, przepisywaniu, regeneracji, modułach i cache nadal widać problemy z obrazami, przywraca się /img/ (i odpowiadające wiersze obrazów w bazie, jeśli trzeba) z sprawdzonej kopii zapasowej. Ręczne ponowne przesyłanie setek produktów jest wolniejsze i łatwo o niezgodność z obrazami kombinacji.
Jak utrzymać działające obrazy po naprawie
- Regularnie twórz kopie zapasowe – obejmują całe drzewo
/img/i bazę danych, nie tylko pliki PHP. - Testuj na stagingu – zmiany motywu, moduły optymalizacji obrazów i duże aktualizacje sprawdza się na kopii przed sklepem produkcyjnym.
- Po dużych zmianach rób kontrolę – po każdej aktualizacji, migracji lub zmianie CDN otwiera się jedną listę kategorii i jedną stronę produktu na mobile i desktop. Potwierdza się, że miniatury i obrazy zoom się ładują, aby wychwycić problemy zanim zrobi to klient.
Większość zgłoszeń o niewyświetlające się obrazy kończy się poprawną domeną sklepu, czytelnymi uprawnieniami /img/, świeżym .htaccess (lub poprawną mapą Nginx), działającym GD/Imagick i ukończoną regeneracją miniatur z wyłączonym kasowaniem przy ponownej próbie. Te kroki wykonuje się, zanim odbuduje się cały katalog.
