PrestaShop: błąd 500 po wyczyszczeniu cache. Przyczyny i naprawa

Błąd 500 po wyczyszczeniu cache w PrestaShop najczęściej oznacza, że pliki w var/cache odtworzył inny użytkownik systemowy niż ten, pod którym działa PHP. Typowo root z crona albo docker exec, podczas gdy PHP-FPM pracuje jako www-data. Naprawa polega na przywróceniu właściciela plików i czyszczeniu cache zawsze jako użytkownik PHP. Dwie inne częste przyczyny to ręcznie skasowany kontener Symfony i nawias klamrowy w szablonie .tpl.

Jak wygląda błąd 500 po czyszczeniu cache?

Sklep przestaje działać zaraz po kliknięciu „Wyczyść pamięć podręczną” albo po nocnym zadaniu, które robi to samo. Czasem pada cały front, czasem tylko część stron. W jednym ze sklepów, którymi się opiekujemy, po pełnym czyszczeniu cache (clearAllCache) w logach pojawiło się 3 593 odpowiedzi 500 w ciągu 2 dni.

Żeby zobaczyć prawdziwy komunikat zamiast pustej strony, włącz na chwilę tryb deweloperski w config/defines.inc.php i przejrzyj logi w var/logs oraz log PHP:

define('_PS_MODE_DEV_', true);

Dlaczego PrestaShop zwraca 500 po wyczyszczeniu cache?

PrestaShop po wyczyszczeniu cache odbudowuje pliki w var/cache przy pierwszym żądaniu albo przy pierwszym poleceniu z konsoli. Jeśli tym pierwszym był root (cron, CLI, docker exec bez -u), nowe pliki należą do roota. PHP-FPM działający jako www-data nie może ich potem odczytać ani nadpisać i zwraca 500.

Jeden z wariantów, który opisał klient: plik var/cache/prod/appParameters.php odtwarzany z uprawnieniami 000 w Dockerze z PHP-FPM. Diagnoza i naprawa:

# ile plików w var/ należy do roota (powinno być 0)
find /var/www/html/var -user root | wc -l

# przywrócenie właściciela
chown -R www-data:www-data /var/www/html/var

# czyszczenie cache jako użytkownik PHP
docker exec -u www-data shop-php php bin/console cache:clear

Od tamtego incydentu w codziennej kontroli sklepu mamy stały punkt: 0 plików należących do root w var/ po każdym czyszczeniu cache.

Masz ten sam problem? Sklep pada po czyszczeniu cache albo po aktualizacji modułu? Znajdziemy przyczynę w logach. Opisz sytuację →

Czy można ręcznie usunąć var/cache/prod?

Nie na żywym sklepie. rm -rf var/cache/prod/* kasuje między innymi skompilowany kontener DI Symfony, a bez niego każde żądanie kończy się błędem 500, dopóki cache się nie odbuduje. Używaj cache:clear albo przycisku w panelu.

Jeśli już musisz usuwać pliki ręcznie, pamiętaj o dwóch pułapkach:

• Glob z sudo. W sudo rm /ścieżka/* gwiazdkę rozwija Twoja powłoka, z Twoimi uprawnieniami, a nie sudo. Uruchamiaj całość w sudo sh -c '...'.
• Po zmianie override usuń var/cache/prod/class_index.php, inaczej PrestaShop nie zauważy nowej klasy.

sudo sh -c 'rm -f /var/www/html/var/cache/prod/class_index.php'

Czy nawias klamrowy w szablonie .tpl może dać błąd 500?

Tak. Każdy { w pliku .tpl Smarty traktuje jako początek tagu. Wystarczy wkleić do szablonu blok CSS w <style>, a kompilacja szablonu się wysypie. U jednego klienta zdarzyło się to 4 razy jednego dnia. CSS i JS w szablonie owijaj w {literal}:

{literal}
<style>
  .promo-bar{background:#111}
</style>
{/literal}

Dlaczego plik PHP wykonuje się mimo chmod 000?

Przez OPcache. Na jednym serwerze chmod 000 nie zatrzymał wykonywania pliku PHP, bo OPcache trzymał skompilowaną wersję w pamięci, mimo że validate_timestamps był włączony. Zadziałała dopiero podmiana treści pliku i restart kontenera PHP-FPM. Zmiana uprawnień nie wyłącza więc kodu, który PHP już ma w pamięci.

Dlaczego cache stron ciągle się czyści?

Ten problem nie daje błędu 500, ale zjada wydajność. Sklep miał własny cache stron dla gości (HTML w var/cache, TTL 12 h). Moduł przy każdym zapisie produktu wołał pełne czyszczenie: cache stron plus purge everything w Cloudflare. Integracje robiły około 300 aktualizacji na godzinę.

Przyczynę znaleźliśmy, szukając /clearAllCache w access logu i filtrując zapytania w Cloudflare GraphQL po ścieżce. Źródłem okazał się adres IP samego serwera. Poprawka: czyszczenie per produkt (jego pliki i purge w Cloudflare po URL), a pełne czyszczenie najwyżej raz na 15 minut. Zanim to zrobiliśmy, cache stron praktycznie nie istniał, a PageSpeed wahał się między 35 a 50 przy LCP 2–4 s.

Warmup, czyli przejście po stronach po zmianach, podniósł cache z 17 do 326 stron. Skrypt trzeba zabezpieczyć flock. Bez niego cron odpalił 9 równoległych procesów i load serwera skoczył do 8,1.

flock -n /tmp/warmup.lock /usr/local/bin/warmup.sh

Uwaga: Cloudflare trzyma osobny wpis cache dla każdego kodowania. Po purge po URL wariant Brotli dalej serwował stary plik. Przy bundlach CSS i JS, których nazwa to hash listy ścieżek, po zmianie samej treści trzeba podbić parametr ?v=.

Skąd 502 i 521 w PrestaShop na Dockerze?

Nginx Proxy Manager przy restarcie regeneruje konfiguracje wszystkich hostów. Jeśli upstreamem jest zatrzymany kontener, w logu pojawia się:

[emerg] host not found in upstream

Wtedy nginx nie wstaje dla żadnej domeny i wszystkie zwracają 521. Cloudflare część ruchu maskował odpowiedziami z cache (HIT), więc awaria wyglądała na częściową. Inny przypadek 502: proxy poza siecią Dockera aplikacji. docker network connect działa, ale znika po odtworzeniu kontenera, więc sieć trzeba wpisać w docker-compose.yml. Jak Docker potrafi też obejść firewall, opisaliśmy przy okazji koparki kinsing na serwerze z Dockerem.

Kiedy zlecić naprawę sklepu?

Gdy 500 wraca po każdym czyszczeniu cache, a nikt nie wie, który cron albo moduł je wywołuje. W ASAPDevs zaczynamy od logów i właścicieli plików, a potem porządkujemy cache tak, żeby sklep był stabilny i szybki. W jednym sklepie PageSpeed karty produktu na mobile wzrósł z 44 do 81. Tak wygląda nasza optymalizacja PrestaShop.