Wprowadzenie

Dlaczego PrestaShop nie działa po migracji serwera to pytanie, które pojawia się zaskakująco często, gdy przenosimy sklep na nowy hosting, nowszą infrastrukturę albo inny adres domeny. Po takiej zmianie sklep potrafi wyświetlać białą stronę, pętlę przekierowań, błędy 500, rozsypane style lub problemy z logowaniem do panelu. Dobra wiadomość jest taka, że w 9 na 10 przypadków da się to szybko naprawić – pod warunkiem, że wiemy, gdzie szukać przyczyny.

Dlaczego PrestaShop nie działa po migracji serwera – najczęstsze przyczyny

• Niezmienione adresy domeny i ścieżki w bazie danych
• Nieaktualne dane dostępu do bazy w plikach konfiguracyjnych
• Różnice w wersji PHP i brak wymaganych rozszerzeń
• Brak lub błędne reguły mod_rewrite (Apache) albo konfiguracja Nginx
• Niewyczyszczona pamięć podręczna i skompilowane szablony
• Nieprawidłowe uprawnienia i właściciel plików po przenosinach
• Konflikty kluczy szyfrujących (cookies, sesje)
• Niekompletna migracja bazy (np. uszkodzone importy, inny prefix tabel)
• Problemy z SSL lub mieszana zawartość po wymuszeniu HTTPS

Już sama ta lista pokazuje, że diagnostyka powinna iść od prostych rzeczy do bardziej zaawansowanych. Poniżej znajdziesz sprawdzony, praktyczny przewodnik.

Adres sklepu: domena, SSL i ścieżki

Najpierw upewnij się, że domena wskazuje na właściwy serwer (rekord A/AAAA w DNS), a SSL jest poprawnie zainstalowany. Następnie:

• W panelu (jeśli działa): Ustawienia -> Ruch i SEO -> Ustawienia adresów -> zaktualizuj domenę, domenę SSL i ścieżkę (base URI).
• Gdy panel nie działa: w bazie danych zaktualizuj tabelę ps_shop_url (pola domain, domain_ssl, physical_uri). W starszych instalacjach sprawdź też ps_configuration (PS_SHOP_DOMAIN, PS_SHOP_DOMAIN_SSL).

Wymuszenie HTTPS bez ważnego certyfikatu albo z błędnym adresem bywają przyczyną pętli przekierowań. Po zmianie adresów zawsze odśwież cache (czytaj dalej).

Pliki konfiguracyjne i dostęp do bazy

Po migracji często zmieniają się host bazy, nazwa, użytkownik i hasło. W PrestaShop zapisane są one w plikach:

• PrestaShop 1.6: config/settings.inc.php
• PrestaShop 1.7: app/config/parameters.php (w nowszych wydaniach czasem config/parameters.php)
• PrestaShop 8: config/parameters.php

Zaktualizuj db_server, db_name, db_user, db_password i prefix (np. ps_). Jeśli prefiks w bazie różni się od tego w pliku, sklep nie zobaczy swoich tabel.

Dodatkowo zweryfikuj zgodność kodowania i silnika tabel (zalecane InnoDB, utf8mb4). Niekompletne importy, przerwane przez timeout lub zbyt mały max_allowed_packet, mogą wywołać błędy 500.

Klucze szyfrujące i sesje

W plikach konfiguracyjnych znajdują się klucze wykorzystywane do szyfrowania cookies i danych. Jeśli przeniesiesz bazę, ale zmienisz te klucze, użytkownicy mogą mieć problem z logowaniem lub zobaczysz dziwne zachowania sesji. Najlepsza praktyka: przenieść te same klucze razem z plikami (nie generować nowych), szczególnie jeśli to tylko zmiana serwera bez zmiany sklepu.

Wersja PHP i rozszerzenia

Często bywa tak, że stary serwer działał na PHP 7.1, a nowy na 8.1 – i nagle część modułów lub motyw przestaje działać. Zasada:

• PrestaShop 1.6: najlepiej PHP 5.6–7.1
• PrestaShop 1.7: zależnie od wydania, zwykle 7.1–7.4
• PrestaShop 8: PHP 8.0/8.1 (zgodnie z dokumentacją danej wersji)

Sprawdź wymagane rozszerzenia: pdo_mysql, cURL, intl, GD, Zip, mbstring, OpenSSL, DOM, SimpleXML. Niekompatybilna wersja PHP to jedna z najczęstszych przyczyn białej strony po migracji.

.htaccess, mod_rewrite i Nginx

Na Apache sklep polega na mod_rewrite i poprawnym pliku .htaccess. Po migracji:

• Upewnij się, że mod_rewrite jest włączony.
• Zregeneruj .htaccess: w panelu wyłącz „Przyjazne adresy URL”, zapisz, włącz ponownie i zapisz.
• Jeśli panel nie działa: tymczasowo usuń .htaccess w katalogu głównym sklepu (system go wygeneruje po ustawieniach), ale miej kopię.

Na Nginx potrzebna jest właściwa konfiguracja reguł przepisywania URL-i (tzw. server block dla PrestaShop). Brak odpowiednich location / index / try_files kończy się 404 lub 500.

Cache i kompilacja Smarty

Po przenosinach pamięć podręczna może pokazywać „stary świat”. Zrób porządki:

• PrestaShop 1.7/8: usuń zawartość katalogów var/cache/prod i var/cache/dev.
• PrestaShop 1.6: wyczyść cache w tools/smarty/compile i tools/smarty/cache oraz usuń cache/class_index.php.

W panelu warto na chwilę włączyć „Kompiluj szablony w razie zmian” oraz wyłączyć cache, aby upewnić się, że wszystko działa. Po migracji czyszczenie cache to obowiązkowy krok.

Uprawnienia i właściciel plików

Niewłaściwe uprawnienia (np. 600 dla katalogów) lub zły właściciel (po rsync lub rozpakowaniu archiwum) powodują błędy zapisu i 500. Bezpieczne minimum:

• Katalogi: 755
• Pliki: 644
• Katalogi wymagające zapisu przez serwer (cache, img, upload, download, var/logs, var/cache, modules niektóre katalogi, translations) – upewnij się, że właścicielem jest użytkownik serwera www (np. www-data) albo nadaj odpowiednie prawa w ramach polityki hostingu.

SSL i mieszana zawartość

Jeśli po przeniesieniu wymuszasz HTTPS, a część zasobów (obrazy, JS, CSS) wciąż ładuje się po HTTP, przeglądarka może je blokować. W rezultacie strona „działa”, ale wygląda jak rozbita. Rozwiązania:

• Zmień adresy zasobów w motywie/modułach na względne lub na https.
• Upewnij się, że domena SSL w ps_shop_url jest poprawna.
• Jeśli używasz CDN lub proxy (np. Cloudflare), sprawdź ustawienia „Flexible/Full SSL” i nagłówki X-Forwarded-Proto.

Tryb DEV i logi – jak szybko złapać błąd

Bez komunikatu błędu błądzimy po omacku. Włącz tryb developerski i odczytaj logi:

• W pliku config/defines.inc.php ustaw PS_MODE_DEV na true.
• Sprawdź logi PHP (error_log) oraz var/logs (w 1.7/8).
• Błędy typu „Class not found”, „Undefined function” często wskazują na wersję PHP/rozszerzenia, a „Access denied” na błędne poświadczenia bazy.

Po rozwiązaniu problemu przywróć tryb produkcyjny (PS_MODE_DEV na false).

Baza danych: import, prefixy i spójność

• Upewnij się, że import objął wszystkie tabele (czasem brakuje np. ps_shop_url lub ps_configuration po obciętym eksporcie).
• Sprawdź prefiks tabel w bazie i ten w pliku konfiguracyjnym – muszą być identyczne.
• Zwróć uwagę na kolacje (zalecana utf8mb4_unicode_ci) i zgodność znaków emoji/MB4, jeśli wcześniej działałeś na utf8.
• Przy bardzo dużych bazach zwiększ limit czasu i pakietu (max_execution_time, max_input_vars, max_allowed_packet).

Lista kontrolna po migracji: krok po kroku

1. Zaktualizuj DNS i poczekaj na propagację.
2. Sprawdź certyfikat SSL na nowym serwerze.
3. Ustaw poprawne dane bazy w parameters.php/settings.inc.php.
4. Zaktualizuj domenę i ścieżki w ps_shop_url (i PS_SHOP_DOMAIN* jeśli dotyczy).
5. Dopasuj wersję PHP do wersji sklepu i włącz wymagane rozszerzenia.
6. Wygeneruj .htaccess i sprawdź reguły Nginx/Apache.
7. Wyczyść cache (var/cache, smarty, class_index).
8. Ustaw właściwe uprawnienia i właściciela plików.
9. Włącz tryb DEV, sprawdź logi, zdiagnozuj ewentualne błędy.
10. Przetestuj front, panel, koszyk, logowanie, płatności i wysyłkę maili.

Czego unikać – typowe pułapki

• „Na siłę” zmienianie kluczy szyfrujących – spowoduje chaos z logowaniem.
• Podbijanie PHP do najnowszej wersji bez sprawdzenia kompatybilności motywu i modułów.
• Regeneracja .htaccess na Nginx (tam .htaccess nie działa) – potrzebna poprawna konfiguracja serwera.
• Migracja tylko plików bez pełnego dumpu bazy (albo odwrotnie).
• Ignorowanie cache i class_index – potrafią trzymać stare definicje klas i szablonów.

Kiedy warto poprosić o pomoc

• Gdy masz do czynienia z dużą, niestandardową instalacją i wieloma modułami komercyjnymi.
• Kiedy logi wskazują na problem w motywie lub module, którego nie możesz zaktualizować.
• Jeśli serwer wymaga specyficznej konfiguracji (np. Nginx + PHP-FPM + reverse proxy, Cloudflare, kontenery).
• Gdy produkcyjny sklep stoi, a każdy błąd kosztuje realną sprzedaż – wtedy liczy się czas reakcji i doświadczenie.

Podsumowanie

Migracja serwera to idealny moment, by „odkurzyć” konfigurację i upewnić się, że wszystko jest spójne: domena, SSL, baza, PHP, cache i uprawnienia. Zdecydowana większość problemów wynika z kilku powtarzalnych błędów konfiguracyjnych, które da się wyłapać, postępując według powyższej listy kontrolnej. Jeśli będziesz działać metodycznie – od adresów i bazy, przez PHP i .htaccess, po cache i uprawnienia – sklep wróci do pełnej sprawności szybciej, niż myślisz. A na przyszłość warto przygotować automatyczny proces deployu, kopie zapasowe i checklistę migracyjną – dzięki temu kolejna przeprowadzka będzie już tylko formalnością.