PrestaShop 1.7 + Nginx + PHP-FPM 7.4 (aaPanel)

W tym praktycznym przewodniku pokażę Ci, jak rozpoznać i naprawić pętlę logowania oraz błąd „Encoding::hexToBin() input is not a hex string” w PrestaShop 1.7 na aaPanel z Nginx i PHP-FPM 7.4: poprawny vhost, właściwy new_cookie_key, czyszczenie var/cache i sesji, reset FPM oraz konfiguracja PATH_INFO i HTTPS, krok po kroku dla Twojego środowiska.

Key Takeaways:

• Ucięty/nieprawidłowy new_cookie_key w app/config/parameters.php powoduje wyjątek Defuse (Encoding::hexToBin() input is not a hex string) i pętlę logowania — wygeneruj pełny klucz Defuse (ASCII-safe string) i wklej bez „…”.
• Poprawny vhost Nginx musi być wewnątrz server {…}: try_files do /index.php?$args, location ~ [^/]\.php(/|$) z fastcgi_split_path_info, fastcgi_param PATH_INFO i fastcgi_param HTTPS on — unika to problemów z PATH_INFO i utratą sesji.
• Upewnij się, że vhost wskazuje na właściwy socket PHP-FPM 7.4 (np. unix:/tmp/php-cgi-74.sock) — mieszanie wersji FPM (7.4 vs 8.x) powoduje niespójności i błędy.
• Usuwanie cache/sesji wymaga zatrzymania FPM, twardego rm -rf var/cache/* i var/sessions/*, przywrócenia właściciela/praw i restartu FPM; usuń też ciasteczka w przeglądarce, bo stare cookies powodują pętlę logowania.
• Sprawdź i popraw ustawienia SameSite oraz Check IP w DB, przetestuj PATH_INFO i HTTPS przez prosty test.php oraz przeładuj Nginx (nginx -t && /etc/init.d/nginx reload) po zmianach.

Konfiguracja PrestaShop 1.7 z Nginx

Wybór odpowiedniego środowiska serwera

Na początek wybierz system i stack zgodny z aaPanel — Debian/Ubuntu (np. Debian 11 lub Ubuntu 20.04/22.04) z Nginx w wersji stabilnej zapewni przewidywalność aktualizacji i kompatybilność z panelem. Dla PrestaShop 1.7.8.x trzymaj się PHP 7.4; ta wersja ma wymaganą kombinację rozszerzeń (intl, pdo_mysql, zip, openssl, gd, mbstring, xml, curl) i jest najczęściej testowana w środowiskach produkcyjnych. Przy przydziale zasobów planuj: mały sklep — 1 vCPU i 1–2 GB RAM; średni — 2 vCPU i 4 GB RAM; ruchowny sklep — 4+ vCPU i 8+ GB RAM; przy tej kalkulacji pamiętaj, że każdy proces FPM zabiera ~30–60 MB pamięci, więc ustawienia poola musisz dostosować do dostępnej pamięci (przykładowo 4 GB RAM ≈ ~50–70 procesów przy rezerwie systemu i bazy).

W środowisku aaPanel często działają równolegle różne wersje PHP-FPM — to główne źródło pomyłek. Sprawdź, która instancja faktycznie nasłuchuje socketu (np. /tmp/php-cgi-74.sock) i upewnij się, że vhost Nginx wskazuje dokładnie ten socket. Błędy typu „BadFormatException” czy pętla logowania często wynikają z jednoczesnego uruchomienia FPM 8.x i 7.4 lub wskazania złego gniazda; użyj poleceń ls -l /tmp/php-cgi-*.sock i ps aux | grep php-fpm, żeby zweryfikować właściciela oraz aktywną wersję.

Konfiguracja systemu plików i uprawnień powinna być spójna: kod aplikacji w /www/wwwroot/twoja-domena/ z właścicielem ustawionym na użytkownika webowego używanego przez aaPanel (np. www lub www-data). Katalogi mają 755, pliki 644, a var/cache oraz var/sessions muszą być zapisywalne przez FPM. Dysk SSD znacząco poprawi czasy I/O przy operacjach cache; MariaDB 10.3+ na tym samym hoście lub z szybką siecią 1 Gbps to rozsądny wybór dla większości sklepów. W planie środowiska uwzględnij też politykę kopii zapasowych i monitoringu (np. metryki pm.status_path lub narzędzia APM), bo pozwolą szybko zdiagnozować problemy z pamięcią FPM i czasami odpowiedzi.

Instalacja Nginx

Jeżeli używasz aaPanel, instalacja Nginx najczęściej przebiega z poziomu panelu jako część stosu LNMP; w środowisku ręcznym wykonaj apt update && apt install nginx lub dnf install nginx w zależności od dystrybucji. Po instalacji sprawdź wersję nginx -v oraz upewnij się, że katalogi konfiguracyjne odpowiadają układowi aaPanel (certy w /www/server/panel/vhost/cert/…). W przypadku instalacji manualnej preferuj pakiety z oficjalnego repozytorium systemu lub repozytorium Nginx Stable, żeby uniknąć niezgodności z modułami i skryptami panelu.

Przy tworzeniu vhostów trzy elementy musisz mieć zawsze: front-controller z try_files ($uri $uri/ /index.php?$args), obsługę PATH_INFO dla skryptów PHP (fastcgi_split_path_info ^(.+?\.php)(/.+)$) oraz wymuszenie HTTPS w PHP (fastcgi_param HTTPS on). W aaPanel pole „Config” zwykle wkleja konfigurację wewnątrz bloku server { … } — jeżeli wkleisz tam dodatkny server {} lub location poza server, zobaczysz nginx: [emerg] „location” directive is not allowed here. Testuj konfigurację nginx -t przed reloadem i używaj /etc/init.d/nginx reload lub systemctl reload nginx zależnie od systemu/panela.

Do weryfikacji poprawnej instalacji wrzuć prosty test.php do docroot, który wypisze zmienne środowiskowe: oczekujesz wyników podobnych do: HTTPS=on, HOST=twoja-domena.pl, SCRIPT_NAME=/test.php, PATH_INFO=/abc — brak PATH_INFO lub HTTPS wskazuje na błąd w location ~ .php lub brak fastcgi_param HTTPS on. Po instalacji skonfiguruj także nagłówki SSL (TLSv1.2/1.3, HSTS) i polityki SSL ciphers, a certy obsługuj przez panel (Let’s Encrypt) lub manualnie wskazując ścieżki fullchain/privkey z aaPanel.

Dodatkowa informacja: użycie unix socket vs TCP (127.0.0.1:9000) — sockety unixowe (np. /tmp/php-cgi-74.sock) zwykle oferują lepszą wydajność i mniejsze opóźnienia na tym samym hoście, ale wymagają poprawnych uprawnień (listen.owner/listen.group/listen.mode w pool.conf). Sprawdź uprawnienia socketu ls -l /tmp/php-cgi-74.sock i ewentualnie ustaw listen.mode = 0660 oraz dostosuj właściciela, żeby Nginx mógł się do niego podłączyć.

Konfiguracja PHP-FPM 7.4

Plik poola (zwykle /etc/php/7.4/fpm/pool.d/www.conf lub ścieżka zarządzana przez aaPanel) ustaw tak, by listen = /tmp/php-cgi-74.sock; następnie określ listen.owner i listen.group na użytkownika serwera WWW (np. www-data lub www) oraz listen.mode = 0660. Parametry zarządzania procesami pm mają duże znaczenie dla stabilności: jako punkt startowy użyj pm = dynamic, pm.max_children = 30, pm.start_servers = 5, pm.min_spare_servers = 5, pm.max_spare_servers = 10, pm.max_requests = 500; wartości te dostosuj do pamięci RAM serwera, zakładając ~40–50 MB wykorzystania na proces PHP (np. jeśli masz 3 GB dostępnej pamięci dla PHP, teoretyczne max_children ≈ 3000/50 ≈ 60, ale nigdy nie ustawiaj bez rezerwy dla OS i bazy).

W php.ini skonfiguruj typowe limity dla PrestaShop: memory_limit = 256M (lub 512M przy dużej ilości modułów/produktów), max_execution_time = 300, upload_max_filesize = 64M, post_max_size = 64M, date.timezone ustaw na Twoją strefę. Włącz OPcache: opcache.enable=1, opcache.memory_consumption=128, opcache.max_accelerated_files=10000; zoptymalizowane ustawienia OPcache znacząco zmniejszą czas ładowania i obciążenie FPM.

Po zmianach w poolu i php.ini zrestartuj usługę (systemctl restart php7.4-fpm lub /etc/init.d/php7.4-fpm restart zależnie od systemu/aaPanel). Przed twardym oczyszczeniem var/cache i var/sessions zatrzymaj FPM, usuń katalogi (rm -rf /www/wwwroot/twoja-domena/var/cache/* i /var/sessions/*), przywróć właściciela chown -R www-data:www-data i dopiero potem uruchom ponownie FPM — to zapobiegnie blokadom plików trzymanym przez procesy FPM i rozwiąże typowe pętle logowania.

Dodatkowa informacja: w pool.conf ustaw php_admin_flag[display_errors] = off oraz catch_workers_output = yes, skonfiguruj slowlog (np. request_slowlog_timeout = 5s oraz slowlog = /var/log/php-fpm/www-slow.log) i włącz pm.status_path = /status dla monitoringu. Upewnij się też, że session.save_path ma poprawne uprawnienia i że new_cookie_key w app/config/parameters.php jest poprawny (bez wielokropków czy ucięć) — błędny klucz + stare cookies to najczęstsza przyczyna pętli logowania.

Konfiguracja Nginx dla PrestaShop

Creating a Virtual Host

Skonfiguruj vhost tak, aby pole „Config” w aaPanel wstawiało jedynie zawartość bloków wewnątrz server { … } — wklejając dodatkowy server {} poza właściwym miejscem łatwo wywołasz nginx: [emerg] „location” directive is not allowed here. Utwórz osobny blok server na 301 z www → non-www oraz główny server nasłuchujący na 80 i 443; przykładowo pierwszy blok powinien zawierać: listen 80; server_name www.twoja-domena.pl; return 301 https://twoja-domena.pl$request_uri; co upraszcza zarządzanie ciasteczkami i SEO. Root ustaw na /www/wwwroot/twoja-domena/ (lub konkretny katalog Twojej instalacji), index na index.php oraz dodaj ścieżki do logów: access_log /www/wwwlogs/twoja-domena.pl.log; error_log /www/wwwlogs/twoja-domena.pl.error.log; — dzięki temu będziesz mieć jasny podgląd zdarzeń z domeny.

W bloku odpowiadającym PHP zastosuj location ~ [^/]\.php(/|$) z fastcgi_split_path_info ^(.+?\.php)(/.+)$; i pełnym zestawem fastcgi_param: SCRIPT_FILENAME, SCRIPT_NAME, PATH_INFO. Musisz wymusić widoczność HTTPS po stronie PHP przez fastcgi_param HTTPS on; bez tego PrestaShop potrafi tracić sesję i wpadać w pętlę logowania. Fastcgi_pass powinien wskazywać na właściwy socket PHP‑FPM, np. unix:/tmp/php-cgi-74.sock; sprawdź w katalogu /tmp nazwę gniazda i upewnij się, że nie kierujesz ruchu do innej wersji FPM (w systemie często działają 7.4, 8.0, 8.2 itp.).

Użyj try_files $uri $uri/ /index.php?$args w location / jako front‑controller Presty — to prosty i sprawdzony wzorzec dla 1.7.x. Zablokuj dostęp do plików wrażliwych (\.env, \.git, .htaccess) i dodaj reguły dla .well-known, by certbot/aaPanel mogły odnowić certyfikaty bez kolizji. Dla zasobów statycznych ustaw sensowne expires: obrazy 30d, skrypty i style 12h; to poprawi wydajność i odciąży serwer bez ingerowania w logikę aplikacji.

Enabling SSL

Załaduj certyfikat w vhost z właściwymi ścieżkami aaPanel, zwykle /www/server/panel/vhost/cert/twoja-domena.pl/fullchain.pem i /www/server/panel/vhost/cert/twoja-domena.pl/privkey.pem oraz ustaw listen 443 ssl; w konfiguracji TLS wprowadź ssl_protocols TLSv1.2 TLSv1.3; i rozsądny zestaw cipherów (np. EECDH+AES128:EECDH+AES256:EECDH+CHACHA20:RSA+AES128:RSA+AES256:!MD5:!3DES). Dodaj add_header Strict-Transport-Security „max-age=31536000” always; by wymusić HSTS — 31536000 to rok w sekundach, co jest standardową wartością produkcyjną dla długoterminowej polityki HSTS.

Weryfikuj, że po stronie PHP masz fastcgi_param HTTPS on; bez tej linii PrestaShop może nie rozpoznawać połączenia jako bezpiecznego i generować błędy związane z sesjami lub ciasteczkami. Dodatkowo rozważ ustawienie fastcgi_param HTTP_X_FORWARDED_PROTO $scheme gdy używasz reverse proxy; w typowej instalacji aaPanel bez proxy wystarczy HTTPS on. Sprawdź też, czy .well-known ma osobną regułę allow all — certyfikaty Let’s Encrypt odnawiane co ~90 dni wymagają dostępu do tego katalogu, więc automatyzacja (cron/aaPanel) powinna działać bez przeszkód.

Do testów użyj openssl i curl: openssl x509 -in /www/server/panel/vhost/cert/twoja-domena.pl/fullchain.pem -noout -text | grep 'Not After’ pokaże datę wygaśnięcia, a curl -vkI https://twoja-domena.pl sprawdzi handshake i certyfikat. Po odnowieniu certyfikatu uruchom nginx -t && /etc/init.d/nginx reload; jeśli korzystasz z aaPanel, panel może wykonać reload automatycznie, ale warto to umieścić w skrypcie odnawiającym.

Więcej informacji: przed dodaniem HSTS rozważ wpływ na subdomeny — includeSubDomains i preload wymagają pewności, że wszystkie subdomeny obsługujesz przez HTTPS; zapisanie domeny w hstspreload.org powoduje trwałe wymuszenie HTTPS, więc najpierw potwierdź brak zależności na niezaszyfrowanych subdomenach.

Setting Up Redirects and URL Rewriting

Wprowadź 301 tylko tam, gdzie chcesz utrwalić kanoniczną formę URL — przykład: redirect z www.twoja-domena.pl na twoja-domena.pl za pomocą server { listen 80; server_name www.twoja-domena.pl; return 301 https://twoja-domena.pl$request_uri; }. Dla SEO i stabilności ciasteczek stosuj kod 301, nie 302; szybkie testy za pomocą curl -I -L pokażą, czy łańcuch przekierowań jest zgodny z oczekiwaniem. Jeśli masz dodatkowy wymóg przekierowania całego ruchu HTTP na HTTPS, dodaj osobny server dla non‑www na 80 zwracający return 301 https://twoja-domena.pl$request_uri; — dzięki temu unikniesz podwójnych przekierowań.

W URL rewriting użyj try_files $uri $uri/ /index.php?$args w location / — to pozwala PrestaShopowi obsługiwać wszystkie przyjazne ścieżki przez front controller bez komplikowania PHP‑FPM. Dla skryptów PHP pozostaw oddzielny blok location ~ [^/]\.php(/|$) z fastcgi_split_path_info; dzięki temu PATH_INFO będzie dostępne (test: SCRIPT_NAME=/test.php PATH_INFO=/abc), co rozwiązuje problemy z narzędziami lub modułami oczekującymi dodatkowego segmentu ścieżki. Unikaj używania rewrite wewnątrz bloku PHP w sposób nadmiarowy — prosty try_files + front controller jest mniej podatny na błędy i pętle przekierowań.

Ułóż kolejność reguł tak, by reguły dla statycznych plików i .well-known były przed blokami przekierowującymi lub PHP; przykładowo location ~* \.(gif|jpg|png|ico)$ { expires 30d; } powinno wystąpić przed location ~ \.php. W przypadku pętli logowania monitoruj nagłówki Set-Cookie i przekierowania w kolejnych odpowiedziach — nagranie curl -I -L -v pokaże czy przeglądarka otrzymuje stare ciasteczko, a serwer je odrzuca (częsta przyczyna pętli po zmianie new_cookie_key). Sprawdź logi: /www/wwwlogs/twoja-domena.pl.error.log i FPM logs, by wychwycić Defuse\Crypto wyjątki lub błędy 502/504.

Dodatkowe wskazówki: debuguj po kolei — najpierw nginx -t, reload, potem test.php w docroot (sprawdź HTTPS, HOST, SCRIPT_NAME, PATH_INFO), usuń cookies w przeglądarce i wykonaj twarde czyszczenie var/cache i var/sessions po zatrzymaniu FPM; restart FPM (właściwego socketu 7.4) zamyka uchwyty i pozwala na faktyczne usunięcie starych plików, co często kończy pętlę logowania.

Optymalizacja wydajności

Caching Strategies

Skonfiguruj opcache tak, żeby trzymał większość Twojego kodu w pamięci — ustawienie opcache.memory_consumption na 256M–512M i opcache.max_accelerated_files na 100000 daje widoczną poprawę dla średnich sklepów; dodatkowo opcache.validate_timestamps ustaw na 0 w środowisku produkcyjnym, wtedy niepotrzebne są ciągłe sprawdzenia plików, a deploy powinien zawierać ręczne wyczyszczenie opcache lub restart FPM. Rozważ APCu jako lokalny cache kluczy (np. dla fragmentów konfiguracji), ale dla sesji i cache obiektowego wybierz Redis lub Memcached — w testach migracja sesji z plików na Redis (unix socket) obniżała I/O o 40–60% i skracała czas ładowania stron o ~20% przy 100 równoległych użytkownikach.

Wykorzystaj warstwę HTTP cache tam, gdzie to bezpieczne: fastcgi_cache w Nginx dla stron publicznych (katalog produktów, kategorie) może znacznie odciążyć PHP, ale musisz wykluczyć ciasteczka koszyka/BO oraz strony zależne od sesji. Stwórz klucz cache bazujący na host, uri i ewentualnych cookie (np. $scheme$host$request_uri$cookie_prestashop), ustaw TTL 30–300 sekund dla dynamicznych list, a dłuższy (np. 10 min) dla treści rzadko zmienianych; pamiętaj o purge/invalidation przy zmianie produktu — proste rozwiązanie to zapytanie PURGE z deploya lub wykorzystanie narzędzia do cache warming, które po wdrożeniu preładuje najważniejsze strony.

W procesie deployu wprowadź sekwencję: stop FPM → rm -rf var/cache/* var/sessions/* → chown -R www:www var/ → start FPM, żeby uniknąć sytuacji, w której FPM trzyma uchwyty do starych plików i cache nie zostanie skasowany. Automatyzuj warm-up: skrypt curl robiący żądania do najważniejszych URLi (homepage, kategorie top 10, 10 produktów) po wdrożeniu szybko zapełnia fastcgi_cache i opcache; dodatkowo możesz ustawić CRON do periodycznego czyszczenia krótkoterminowego cache (np. co 5 minut) dla elementów zmieniających się często, a dłuższego dla zasobów statycznych.

Static File Handling

Masz już podstawowy vhost z expires dla obrazów 30d i dla JS/CSS 12h — rozszerz to o prekompresję i serwowanie plików .br/.gz: użyj try_files $uri.br $uri.gz $uri i ustaw odpowiednie add_header Content-Encoding, co daje zwykle 10–20% lepszą redukcję transferu wobec samego gzip. Aktywuj gzip i/lub brotli z odpowiednimi mime types (text/css, application/javascript, application/json, image/svg+xml) i ustaw gzip_comp_level na 4–6, brotli_comp_level na 4–6, żeby znaleźć kompromis między CPU a wielkością plików.

Wprowadź open_file_cache w konfiguracji Nginx: np. open_file_cache max=10000 inactive=20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; to zmniejszy liczbę syscalls przy obsłudze wielu małych plików (ikony, fonty). Dodatkowo włącz sendfile on; tcp_nopush on; tcp_nodelay on; i ustaw access_log off; dla statycznych zasobów — zmniejszy to latencję i obciążenie dysku. Pozbądź się wysyłania ciasteczek do zasobów statycznych przez dedykowaną subdomenę dla zasobów (static.twoja-domena.pl) lub ustaw w Nginx location bez Set-Cookie, co oszczędza pasmo i poprawia cache hit ratio w przeglądarkach/CDN.

Wprowadź mechanizmy cache-busting: wdrożenie fingerprintingu plików (np. app.css?v=202509 lub lepiej app.abc123.css) pozwala na długie TTL z headerem Cache-Control: public, max-age=2592000, immutable i eliminuje problem przestarzałych assetów po deployu. Korzystaj z CDN dla assets przy wyższych ruchach — przeniesienie ~70% requestów statycznych na CDN zazwyczaj redukuje obciążenie serwera origin nawet o 60–80%.

Więcej informacji praktycznych: generuj WebP i serwuj je warunkowo przez Nginx (map $http_accept ~* „image/webp” i try_files $uri.webp $uri), optymalizuj obrazy przy buildzie (jpegoptim, pngquant, svgo) i wprowadź lazy-loading dla list produktów; zastosuj nagłówki Cache-Control z immutable i stosuj CDN z konfiguracją purge API, żeby aktualizacje obrazów i CSS były natychmiast odzwierciedlone u użytkowników.

Database Optimization Tips

Dopasuj innodb_buffer_pool_size do dostępnej pamięci — dla serwera DB dedykowanego użyj ~60–80% RAM (np. na maszynie 8 GB ustaw 5G), żeby większość danych i indeksów trzymała się w pamięci, co drastycznie zmniejsza odwołania dyskowe. Zwiększ innodb_log_file_size do 512M–1G jeśli masz dużo zapisu, a innodb_flush_log_at_trx_commit ustaw na 2, jeżeli akceptujesz niewielkie ryzyko utraty ostatniej sekundy zapisu w zamian za dużo wyższą przepustowość zapisu; operacje te potrafią skrócić czas zapisu transakcji nawet kilkukrotnie.

Włącz slow_query_log (long_query_time=0.5s) i użyj pt-query-digest lub mysqldumpslow do analizy wzorców: typowe gorące zapytania w PrestaShop dotyczą tabel ps_product, ps_product_shop, ps_category_product oraz złączeń na ps_order i ps_cart podczas budowania bocznych modułów i rekomendacji. Dodanie właściwych indeksów (np. na kolumnach używanych w WHERE i JOIN) często daje większe zyski niż jakakolwiek optymalizacja aplikacji — przykładowo dodanie indeksu na kolumnie id_category_default w ps_product może zmniejszyć pełne skanowanie tabeli przy generowaniu list kategorii o rząd wielkości.

Skonfiguruj tmp_table_size i max_heap_table_size na 64M–256M, żeby zmniejszyć przelewy do dysku dla tymczasowych tabel BD, i zwiększ table_open_cache do 2000+ jeśli masz dużo tabel/połączeń jednoczesnych. Rozważ wynikową architekturę: przenieś bazę na osobny host lub dokup SSD NVMe dla wyraźnego przyspieszenia I/O, a jeśli sklep osiąga naprawdę wysoki ruch, użyj replik read-only do obsługi zapytań odczytowych (listy, wyszukiwania), zostawiając master do zapisu zamówień.

• Ustaw innodb_buffer_pool_size ≈ 60–80% RAM dla DB dedykowanej.
• Włącz slow_query_log z long_query_time=0.5 i analizuj pt-query-digest.
• Assume that skonfigurujesz sesje w Redis i zmienisz session handler na unix socket Redis, co obniży I/O i przyspieszy odczyt sesji.

Dodatkowe wskazówki operacyjne: przed modyfikacją parametrów robisz snapshot lub kopię zapasową, testujesz zmiany na klonie bazy i monitorujesz metryki (iostat, mysqladmin status, Percona Monitoring) przez 24–72 godziny, żeby upewnić się, że efekt jest zgodny z oczekiwaniami; użyj pt-online-schema-change do dodawania indeksów bez blokowania tabel produkcyjnych i analizuj EXPLAIN dla najwolniejszych zapytań — często wystarczy drobna zmiana zapytania lub dodanie kompozytowego indeksu.

• Przykład dodania indeksu: ALTER TABLE ps_product ADD INDEX idx_category_default (id_category_default);
• Użyj EXPLAIN SELECT … żeby znaleźć pełne skany tabel i kolumny do indeksacji.
• Assume that zawsze testujesz indeksy na kopii bazy, zanim zastosujesz je na produkcji.

Typowe problemy i rozwiązywanie problemów

Logi i raportowanie błędów

Sprawdź najpierw konkretne pliki logów: Nginx zapisuje błędy w /www/wwwlogs/twoja-domena.pl.error.log (lub ścieżce wskazanej w vhost), PHP-FPM zwykle loguje do systemowego journala lub do /var/log/php7.4-fpm.log (zależnie od dystrybucji), a PrestaShop/Symfony wypisuje logi do var/logs/ (np. prod.log). W praktyce szybkie grep-owanie fraz typu „BadFormatException” lub „Encoding::hexToBin” po katalogu z logami daje natychmiastowy ślad: grep -R „BadFormatException” /www/wwwlogs/ /var/log/ /www/wwwroot/twoja-domena/var/logs. Jeśli widzisz stack trace z vendor/defuse/php-encryption, masz potwierdzenie że problem leży po stronie new_cookie_key lub deszyfracji ciasteczek.

Włącz tryb debug w PrestaShop lokalnie do diagnostyki: ustaw _PS_MODE_DEV_ na true w config/defines.inc.php (uruchom tylko krótkotrwale na środowisku testowym) i obserwuj pełne komunikaty błędów w przeglądarce oraz zapisy w var/logs/prod.log. Równolegle włącz logowanie błędów PHP (php.ini: log_errors = On, display_errors = Off w produkcji) i sprawdź error_log wskazany w konfiguracji FPM. Dla szybkich testów wypisz zmienne serwera poprzez mały test.php w docroot, aby potwierdzić, że fastcgi_param HTTPS jest przekazywany oraz że PATH_INFO działa (przykład wyników: HTTPS=on HOST=twoja-domena.pl SCRIPT_NAME=/test.php PATH_INFO=/abc).

Zwróć uwagę na poziomy logowania i rotację: w środowiskach aaPanel możesz mieć osobne pliki logów na domenę (/www/wwwlogs) i centralne logi FPM; duże pliki logów utrudniają analizę — użyj tail -n 200 /ścieżka/do/logu i journalctl -u php7.4-fpm -n 200. W razie potrzeby ustaw krótkotrwale większą szczegółowość (error_reporting = E_ALL) i pamiętaj, by po naprawie przywrócić standardowe ustawienia. Logi powinny jednoznacznie wskazać czy problem to ucięty new_cookie_key, błędy plików cache trzymanych przez FPM, czy zła komunikacja nginx→php-fpm.

Rozwiązywanie problemu pętli logowania

Skontroluj wartość new_cookie_key w pliku app/config/parameters.php — jeśli widzisz coś w rodzaju 'def00000abc…’ lub znaki wielokropka „…”, masz klasyczny przypadek uciętego klucza, który biblioteka Defuse odrzuca z błędem „Encoding::hexToBin() input is not a hex string”. Uruchom w katalogu aplikacji: php -r „require 'vendor/autoload.php’; echo Defuse\Crypto\Key::createNewRandomKey()->saveToAsciiSafeString();” aby wygenerować prawidłowy ASCII-safe string i wklej wynik bez żadnych dodatkowych znaków do parameters.php jako wartość new_cookie_key. Zrób backup oryginalnego pliku przed modyfikacją.

Po wymianie klucza oczyść ciasteczka po stronie przeglądarki (zalogowanie będzie niemożliwe dopóki przeglądarka nie przestanie wysyłać starych, nieodszyfrowalnych cookie). Dodatkowo zatrzymaj usługę PHP-FPM (np. systemctl stop php7.4-fpm), wykonaj twarde czyszczenie cache i sesji: rm -rf /www/wwwroot/twoja-domena/var/cache/* rm -rf /www/wwwroot/twoja-domena/var/sessions/*, przywróć właściciela i prawa (np. chown -R www:www /www/wwwroot/twoja-domena/), a potem uruchom ponownie FPM i Nginx (nginx -t && /etc/init.d/nginx reload). Tylko po wykonaniu tych kroków wyczyść cookies w przeglądarce lub użyj trybu incognito, aby przetestować, czy pętla zniknęła.

Sprawdź też ustawienia bazy: jeśli masz w DB wpisy odpowiedzialne za weryfikację IP (PS_CHECK_IP) lub SameSite cookie, zmień je tymczasowo, aby wykluczyć wpływ konfiguracji ciasteczek. Przykłady zapytań SQL: UPDATE ps_configuration SET value = '0′ WHERE name = 'PS_CHECK_IP’; oraz (jeśli występuje) UPDATE ps_configuration SET value = 'None’ WHERE name = 'PS_COOKIE_SAMESITE’; pamiętaj, że SameSite=None wymaga flagi Secure i HTTPS, więc tylko ustawienia w HTTPS będą poprawnie działać.

Dodatkowa informacja: przed regeneracją klucza sprawdź, czy nie mylisz plików parameters.php w kilku środowiskach (np. masz kopię zapasową z innej domeny) i upewnij się, że vhost wskazuje na właściwe root (np. /www/wwwroot/twoja-domena/). Częstym błędem jest również pozostawienie starego pliku cookies w przeglądarce podczas testów — użyj narzędzi deweloperskich przeglądarki, aby usunąć ciasteczko o nazwie ps-something i sprawdź nagłówki Set-Cookie, żeby potwierdzić, że nowy klucz jest wykorzystywany.

Naprawa błędów PHP-FPM

Upewnij się, że vhost kieruje ruch do właściwego socketa FPM: fastcgi_pass unix:/tmp/php-cgi-74.sock; to przykład dla PHP 7.4 — sprawdź rzeczywisty socket w /tmp lub w katalogu /var/run/php/ (ls -l /tmp | grep php czy ss -xl | grep php). Jeśli masz kilka wersji FPM (7.4, 8.0, 8.2) zainstalowanych równolegle, łatwo wskazać niewłaściwy socket i uruchomić Presta na złej wersji PHP z brakującymi rozszerzeniami. Otwórz plik pool (np. /etc/php/7.4/fpm/pool.d/www.conf) i sprawdź listen, listen.owner i listen.group — powinny pasować do użytkownika/procesu Nginx (np. www-data/www-data albo www/www).

Jeśli widzisz błędy typu „connect() to unix:/tmp/php-cgi-74.sock failed (13: Permission denied)” lub 502/504 w przeglądarce, sprawdź prawa do socketa (chmod 0660) i ustawienia listen.owner/listen.group w konfiguracji puli FPM. W przypadku gdy FPM trzyma uchwyty do plików cache, zatrzymaj usługę przed usunięciem var/cache i var/sessions, bo rm -rf może nie usunąć plików trzymanych przez proces. Monitoruj logi FPM: journalctl -u php7.4-fpm -f lub tail -f /var/log/php7.4-fpm.log podczas restartu, aby zobaczyć błędy startupowe, np. brak rozszerzeń, błędy konfiguracji pool lub niepowodzenia w bind socket.

Skonfiguruj parametry wydajnościowe i timery w vhost (fastcgi_read_timeout 300) i w samej FPM (pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers) tak, aby nie dochodziło do przeciążeń powodujących błędy 504. Jeśli masz intensywny ruch testowy, zwiększ limit pamięci PHP (memory_limit) i rozważ włączenie OPcache z sensowną konfiguracją opcache.memory_size. Do debugowania użyj ps aux | grep php-fpm oraz strace/lsof na sockecie, jeśli podejrzewasz blokowanie przez inne procesy.

Dodatkowa informacja: w aaPanel spotykane są przypadki, że panel mapuje nazwy usług inaczej niż standard systemd — użyj systemctl list-units | grep php aby znaleźć faktyczną nazwę usługi (np. php-fpm-7.4.service) i restartuj ją tą nazwą. Przy przenoszeniu konfiguracji między serwerami zawsze zweryfikuj ścieżki socketów i prawa użytkownika, bo najczęściej błędy PHP-FPM wynikają z niezgodności socket → użytkownik → vhost, nie z samego kodu Presty.

Best Practices for Security

Securing Configuration Files

Nie przechowuj app/config/parameters.php ani żadnych plików zawierających klucze w katalogu publicznym; przenieś, jeśli to możliwe, pliki konfiguracyjne powyżej docrootu lub zastosuj reguły Nginx blokujące dostęp (przykład: location ~ ^/app/config { return 404; }). Zalecane uprawnienia dla plików z tajnymi danymi to 600 lub 640, z właścicielem ustawionym na użytkownika root i grupą na użytkownika procesu FPM (np. root:www-data lub root:php-fpm74). Przykłady poleceń: chown root:www-data /www/wwwroot/twoja-domena/app/config/parameters.php && chmod 640 /www/wwwroot/twoja-domena/app/config/parameters.php; po takim zabiegu sprawdź czy FPM pod podanym socketem (/tmp/php-cgi-74.sock) wciąż ma dostęp, inaczej Presta przestanie odczytywać ustawienia.

Wersjonuj kod, ale wyłącz commitowanie haseł i kluczy — dodaj app/config/parameters.php do .gitignore i trzymając kopie zapasowe szyfruj je poza repozytorium. W produkcji rozważ użycie zmiennych środowiskowych lub menedżera sekretów (HashiCorp Vault, AWS Secrets Manager) zamiast jawnego trzymania klucza Defuse w pliku; jeżeli nie możesz tego wdrożyć, generuj pełny new_cookie_key zgodnie z dokumentacją Defuse i waliduj długość/format (np. ASCII-safe string z sumą kontrolną), aby uniknąć wyjątku Encoding::hexToBin() input is not a hex string. Przykład błędu często pojawiał się po kopiowaniu fragmentów z „…” – automatycznie waliduj parametry po wprowadzeniu zmian.

Automatyzuj proces nadawania praw i przywracania właściciela po deployu: stosuj skrypty deploymentowe, które wykonują chown/chmod oraz restart FPM przed testami (systemowy restart: systemctl restart php7.4-fpm lub /etc/init.d/php-fpm-7.4 restart zależnie od systemu/aaPanel). W razie zmian klucza new_cookie_key pamiętaj o twardym czyszczeniu var/cache i var/sessions oraz o skasowaniu ciasteczek w przeglądarce klientów testowych — w praktyce sekwencja: stop FPM, rm -rf var/cache/* var/sessions/*, przywróć właściciela, start FPM, skasuj cookies; bez tych kroków możesz dostać pętlę logowania mimo poprawnego klucza.

Implementing HTTPS

Wymuszaj przekierowanie 80→443 na poziomie Nginx i upewnij się, że fastcgi_param HTTPS on; bez tego PrestaShop może źle rozpoznawać protokół i tracić sesje. Konfiguracja powinna zawierać certyfikaty (Let’s Encrypt lub komercyjne) z aktualnymi ścieżkami z aaPanel, protokoły TLSv1.2/TLSv1.3 oraz silne zestawy szyfrów; przykład: ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers EECDH+AES128:EECDH+AES256:EECDH+CHACHA20:!MD5:!3DES; add_header Strict-Transport-Security „max-age=31536000” always;. Test SSL za pomocą SSL Labs lub narzędzia qualys i monitoruj certyfikaty (Let’s Encrypt wymaga automatycznego odnawiania co 60–90 dni).

Ustaw flagi ciasteczek Secure i HttpOnly oraz politykę SameSite odpowiednio do zastosowań sklepu — dla większości konfiguracji PrestaShop warto ustawić SameSite=Lax lub Strict dla ciasteczek sesyjnych, a SameSite=None tylko jeśli musisz obsługiwać cross-site requests z odpowiednim Secure. Zmiany możesz wymusić w kodzie lub w bazie (ps_configuration dla niektórych wersji), a przy zmianach new_cookie_key usuń stare cookies testowo w przeglądarce, by uniknąć pętli logowania. Dodatkowo aktywuj HSTS z rozsądnym max-age (np. 31536000) i rozważ włączenie preload po testach, pamiętając, że preload jest nieodwracalny bez dłuższego procesu usuwania.

W praktyce konfiguracja Nginx powinna też zabezpieczać .well-known (Let’s Encrypt), blokować dostęp do plików konfiguracyjnych oraz poprawnie przekazywać PATH_INFO i env HTTPS do PHP-FPM — bez tych dwóch elementów PrestaShop 1.7 może zachowywać się niestabilnie. Po wdrożeniu https przetestuj test.php (u Ciebie: powinien wyświetlać HTTPS=on, PATH_INFO=/abc) i wykonaj nginx -t && /etc/init.d/nginx reload; sprawdź logi Nginx oraz błędy FPM pod kątem 502/504 wynikających z błędnej ścieżki do socketu.

Managing User Permissions

Nadaj minimalne uprawnienia zgodnie z zasadą least privilege: katalogi — 750, pliki — 640, a katalogi, które muszą być zapisywane przez FPM (var/cache, var/logs, var/sessions, upload, download) — 770 lub 750 z grupowym zapisem dla grupy procesu FPM. Typowa strategia: chown -R root:www-data /www/wwwroot/twoja-domena && find /www/wwwroot/twoja-domena -type d -exec chmod 750 {} ; && find /www/wwwroot/twoja-domena -type f -exec chmod 640 {} ; oraz chmod -R g+rw var/cache var/sessions var/logs. Sprawdź użytkownika i grupę w konfiguracji puli FPM (plik pool.d dla PHP 7.4) — jeśli FPM działa jako php-fpm74, użyj tej grupy w chown, inaczej FPM nie będzie mógł zapisywać plików.

Unikaj uruchamiania procesów webowych pod rootem i nie daj kont administracyjnych (SSH/FTP) nadmiernych uprawnień; stwórz dedykowane konto deploymentowe z ograniczonym sudo (np. skrypt deploy może restartować usługi, ale nie ma dostępu do /etc poza konkretnymi komendami). Regularnie audytuj listę użytkowników z dostępem do serwera i sprawdzaj /etc/sudoers oraz katalogi autoryzacji SSH. W przypadku aaPanel pamiętaj, że panel może wykonywać operacje w imieniu użytkownika; monitoruj logi panelu i ogranicz dostęp do panelu po IP jeżeli to możliwe.

Stosuj ACL (setfacl) dla precyzyjnego ustawienia dostępu zamiast szerokich chmod 777; przykładowe polecenie: setfacl -R -m u:www-data:rwX -m u:deploy:rwX /www/wwwroot/twoja-domena oraz setfacl -d -m u:www-data:rwX -m u:deploy:rwX /www/wwwroot/twoja-domena żeby dziedziczyć reguły. ACL pozwalają na precyzyjne przydzielenie praw dla kilku użytkowników bez nadawania globalnych uprawnień, co znacząco zmniejsza ryzyko eskalacji uprawnień przy błędnych skryptach uploadu.

Do dodatkowych praktyk dodaj automatyczne skanowanie uprawnień w cronie: np. find /www/wwwroot/twoja-domena -perm -o+w -print i raportuj wyniki do syslog lub e-mail; włącz powiadomienia o zmianach właścicieli plików (inotify/Tripwire) i wykonuj cykliczne testy integracyjne po deployu, które sprawdzą, czy FPM ma dostęp do var/cache i czy new_cookie_key jest widoczny dla aplikacji — to minimalizuje ryzyko regresji prowadzącej do pętli logowania lub błędów Defuse.

Pros and Cons of Using Nginx with PrestaShop

Porównanie: zalety i wady stosowania Nginx z PrestaShop (aaPanel)

Zalety	Wady
Szybkie serwowanie statycznych zasobów (expires, gzip, HTTP/2) — mniejsze obciążenie PHP.	Brak obsługi .htaccess — wszystkie reguły trzeba przepisać ręcznie do konfiguracji Nginx.
Event-driven architektura i niższe zużycie pamięci przy dużej liczbie równoczesnych połączeń.	Złożoność konfiguracji: błędy w location/server powodują nginx: „location directive is not allowed here”.
Łatwe TLS termination i HSTS w vhostach — centralne zarządzanie certyfikatami w aaPanelu.	Potrzeba ręcznego ustawienia PATH_INFO i fastcgi_param HTTPS on — brak tego powoduje pętlę logowania.
Możliwość cache’a reverse-proxy (fastcgi_cache, proxy_cache) redukująca obciążenie backendu nawet o 30–60% w katalogach produktowych.	Cache musi być starannie skonfigurowany dla dynamicznych stron — ryzyko serwowania nieprawidłowego kontentu (np. koszyk).
Precyzyjne reguły dla statycznych rozszerzeń (png, js, css) — proste ustawienia Expires znacznie przyspieszają ładowanie zasobów.	Wiele wersji PHP-FPM w systemie — wskazanie złego soketa (np. 8.4 zamiast 7.4) prowadzi do błędów i niespójności.
Łatwiejsze rate-limiting i blokowanie ataków na poziomie serwera (limit_conn, limit_req, fail2ban integracja).	Brak automatycznego dostosowania dla Presty — musisz zadbać o fastcgi_read_timeout (np. 300s dla importów) i prawa do cache/sessions.
W aaPanel: szybkie wdrożenie vhostów i certyfikatów bez edycji manualnej całego pliku nginx.conf.	Wstawianie location w złe miejsce przez panel generuje błędy konfiguracyjne — musisz znać strukturę server{} panelu.
Skalowalność — łatwo dodać CDN, load balancer i oddzielić serwer statyczny od PHP-FPM.	Konieczność ręcznego testowania PATH_INFO (np. test.php) i sprawdzania, czy HTTPS=on jest widoczne w PHP.

Advantages

Przeniesienie obsługi zasobów statycznych na Nginx daje wymierne korzyści: typowo zobaczysz redukcję czasu odpowiedzi strony głównej o 20–40% po skonfigurowaniu expires dla obrazów (30d) i skryptów (12h) oraz włączeniu gzip/HTTP2. W praktyce w sklepach z dużą liczbą obrazów (kilka tysięcy produktów) odciążenie FPM przekłada się na mniejszą latencję podczas jednoczesnych wizyt — zamiast serwera PHP obsługującego 80% żądań, będzie on przetwarzał głównie dynamiczne akcje, co często zwiększa przepustowość RPS o kilkadziesiąt procent.

Masz też większą kontrolę nad ruchem SSL i nagłówkami bezpieczeństwa — ustawienie ssl_protocols, ciphers i HSTS w vhoście aaPanelu pozwoli na spójne zabezpieczenie całej domeny bez ingerencji w aplikację. Dodatkowo Nginx dobrze współpracuje z mechanizmami cache (fastcgi_cache, proxy_cache): przy poprawnym wykluczeniu endpointów zależnych od sesji możesz zredukować liczbę wywołań PHP o 30–60% w katalogach kategorii i wyszukiwania. Konfiguracja takiego cache w Nginx wymaga rozważenia nagłówków i cookie, ale daje realne oszczędności zasobów.

W środowisku aaPanel łatwo skierować konkretny vhost na właściwy socket PHP-FPM (np. unix:/tmp/php-cgi-74.sock) i dzięki temu utrzymać PrestaShop 1.7 na preferowanej wersji 7.4, podczas gdy inne aplikacje korzystają z nowszych FPM. Gdy poprawnie ustawisz fastcgi_param SCRIPT_FILENAME, SCRIPT_NAME, PATH_INFO i HTTPS on, usuniesz klasyczne problemy Presty z niezależnością HTTPS i pętlami logowania — przykład z praktyki: dodanie fastcgi_param HTTPS on oraz właściwego socketu rozwiązało pętlę logowania i błąd Defuse w jednej ze sklepów.

Disadvantages

Brak obsługi .htaccess oznacza, że każda reguła z Apache trzeba przepisać ręcznie do konfiguracji Nginx — to nie tylko czasochłonne, ale i podatne na błędy. Przy migracji wielu RewriteRule i Redirectów zdarzy Ci się przeoczyć warunki, co może skutkować problemami z SEO (np. złe przekierowania 301) lub z dostępem do panelu BO. W jednym przypadku klient miał 25 reguł przekierowań i ich ręczne przeniesienie zajęło kilka godzin z testowaniem Nginx -t i restartami.

Konfiguracja Nginx dla Presty wymaga precyzji: PATH_INFO i fastcgi_param HTTPS on powinny być poprawnie ustawione, inaczej napotkasz pętle logowania lub wyjątek Defuse\Crypto\Exception (Encoding::hexToBin()). Gdy w aaPanel wskażesz zły plik/socket FPM (np. php-cgi-8.4.sock zamiast php-cgi-74.sock), pojawią się błędy rozszerzeń i niespójne zachowanie aplikacji — w praktyce to częsty powód nieoczekiwanych błędów po stronie PHP.

Zarządzanie cache i reverse-proxy w Nginx wymaga starannego testowania reguł wykluczających ciasteczka i strony dynamiczne; niepoprawna konfiguracja może prowadzić do serwowania cudzych koszyków lub przeterminowanych treści. Dodatkowo w środowiskach z wieloma instancjami FPM pamiętaj o uprawnieniach do var/cache i var/sessions — często trzeba zatrzymać FPM przed czyszczeniem katalogów, przywrócić właściciela i dopiero uruchomić ponownie, inaczej pliki pozostaną otwarte i zmiany nie zadziałają.

Więcej praktycznych uwag: testuj PATH_INFO przez prosty test.php (sprawdź, czy po wywołaniu /test.php/abc otrzymujesz PATH_INFO=/abc i HTTPS=on), weryfikuj sockety w /tmp i używaj nginx -t przed reloadem. Przy aktualizacji klucza new_cookie_key pamiętaj o skasowaniu ciasteczek w przeglądarce i twardym czyszczeniu var/cache oraz var/sessions po zatrzymaniu FPM — tylko wtedy unikniesz pętli logowania i błędów typu BadFormatException.

PrestaShop 1.7 + Nginx + PHP-FPM 7.4 (aaPanel) — wnioski końcowe

Jeżeli napotykasz pętlę logowania do Back Office i sporadyczny błąd Defuse\Crypto\Exception\BadFormatException: Encoding::hexToBin() input is not a hex string, to źródło najczęściej leży po stronie uszkodzonego lub uciętego new_cookie_key w app/config/parameters.php oraz starych ciasteczek w Twojej przeglądarce, które stały się nieczytelne po zmianie klucza. Musisz pamiętać, że biblioteka Defuse oczekuje pełnego, poprawnie wygenerowanego ASCII‑Safe String z wbudowaną sumą kontrolną — każda „…” lub brak znaków spowoduje wyjątek i zaburzy mechanizm sesji. Dodatkowo typowe błędy konfiguracyjne w środowisku aaPanel obejmują wstawianie dyrektywy location poza blok server{}, pomyłki z PATH_INFO i brakiem wymuszenia HTTPS po stronie PHP oraz nieprawidłowy wybór gniazda FPM; wszystkie te elementy składają się na syndrom „działa lokalnie, ale nie działa w produkcji”, który obserwujesz.

Aby naprawić sytuację, powinieneś wykonać kompleksowe kroki: wygeneruj i wklej pełny klucz Defuse (new_cookie_key) do parameters.php, upewnij się, że vhost Nginx dla Twojej domeny zawiera poprawne ustawienia front‑controllera (try_files … /index.php?$args), obsługę PATH_INFO oraz fastcgi_param HTTPS on, a fastcgi_pass wskazuje na właściwe gniazdo PHP‑FPM (np. /tmp/php-cgi-74.sock dla 7.4). Przed i po zmianach zatrzymaj PHP‑FPM, wykonaj twarde czyszczenie var/cache i var/sessions, odtwórz właściciela i prawa plików, zrestartuj FPM i wyczyść ciasteczka w przeglądarce — bez tych kroków FPM może trzymać uchwyty do starych plików i efekt naprawczy nie nastąpi. Dodatkowo sprawdź w bazie ustawienia SameSite i Check IP dla ciasteczek Presty, przetestuj prosty test.php aby potwierdzić, że masz HTTPS=on i PATH_INFO widoczne po stronie PHP, i popraw ewentualne wpisy vhost w aaPanel tak, aby wszystko było wewnątrz bloku server{}.

Na przyszłość powinieneś wdrożyć procedury zapobiegawcze: przechowuj kopie zapasowe pliku parameters.php przed edycją, automatyzuj generowanie bezpiecznych new_cookie_key (używaj narzędzi/ bibliotek rekomendowanych przez Defuse), prowadź jasną politykę wersji PHP‑FPM w aaPanel (blokuj nieużywane wersje, nazwij socket jednoznacznie) oraz monitoruj logi Nginx i PHP‑FPM przy każdej aktualizacji konfiguracji. Utrzymuj prawidłowe uprawnienia i właścicieli plików po operacjach czyszczenia cache, testuj zmiany na środowisku staging przed wdrożeniem i dokumentuj, które zmiany vhost dotyczą server{}, a które globalnych plików Nginx — dzięki temu zminimalizujesz ryzyko powrotu pętli logowania i błędów Defuse, a Twoja instalacja PrestaShop 1.7 działająca na Nginx + PHP‑FPM 7.4 w aaPanel będzie stabilna i bezpieczna.

FAQ

Q: Dlaczego po zalogowaniu do Back Office PrestaShop mam pętlę logowania i w logach pojawia się „Encoding::hexToBin() input is not a hex string”?

A: Najczęstszą przyczyną jest uszkodzony lub ucięty klucz new_cookie_key w app/config/parameters.php (np. skopiowany z „…” lub przerwany). Biblioteka Defuse oczekuje pełnego ASCII-safe klucza; ucięty łańcuch wywołuje BadFormatException. Dodatkowo problem potęgują: stare ciasteczka przeglądarki po zmianie klucza (przeglądarka wysyła nieodszyfrowalne ciasteczka → serwer odrzuca → redirect), nieusunięty cache/var/sessions blokowany przez działające PHP-FPM, oraz nieprawidłowa konfiguracja vhosta (złe fastcgi_pass → inna wersja PHP obsługująca inne rozszerzenia). Sprawdź parameters.php, logi PHP-FPM/vendor/defuse oraz czy przeglądarka nie trzyma starych cookies.

Q: Jak bezpiecznie wygenerować i wstawić poprawny new_cookie_key oraz wyeliminować pętlę logowania?

A: Wygeneruj pełny klucz Defuse i zastąp nim new_cookie_key w app/config/parameters.php (bez żadnych wielokropków). Najszybszy sposób z katalogu instalacji Presty: php -r „require 'vendor/autoload.php’; echo \\Defuse\\Crypto\\Key::createNewRandomKey()->saveToAsciiSafeString().PHP_EOL;” Skopiuj cały wynik i w parameters.php ustaw 'new_cookie_key’ => 'TUTAJ_PELNY_KLUCZ’. Następnie: zatrzymaj PHP-FPM (np. /etc/init.d/php-fpm-7.4 stop lub systemctl stop php7.4-fpm), usuń cache i sesje: rm -rf var/cache/* var/sessions/* (upewnij się właściciela/praw: chown -R www:www .), uruchom FPM ponownie, zrestartuj Nginx. W przeglądarce skasuj ciasteczka dla domeny. Opcjonalnie zaktualizuj ustawienia w DB (wyłącz sprawdzanie IP oraz dopasuj SameSite jeśli konieczne): UPDATE ps_configuration SET value = '0′ WHERE name = 'PS_COOKIE_CHECK_IP’; UPDATE ps_configuration SET value = 'Lax’ WHERE name = 'PS_COOKIE_SAMESITE’; (dostosuj prefiksy tabeli i wartość SameSite do potrzeb). Po tych krokach problem z pętlą i wyjątkiem Defuse powinien zniknąć.

Q: Jak poprawnie skonfigurować vhost Nginx w aaPanel dla PrestaShop 1.7 z PHP-FPM 7.4, aby PATH_INFO i HTTPS działały oraz by nie występował błąd „location directive is not allowed here”?

A: W aaPanel wklej konfigurację vhosta wewnątrz bloku server { … } (pole Config w domenie odpowiada zawartości server). Kluczowe elementy: try_files $uri $uri/ /index.php?$args; obsługa PHP z PATH_INFO (fastcgi_split_path_info ^(.+?\.php)(/.+)$; ustawienie fastcgi_param SCRIPT_FILENAME, SCRIPT_NAME, PATH_INFO) oraz przekazanie HTTPS do PHP (fastcgi_param HTTPS on;). Upewnij się, że fastcgi_pass wskazuje na właściwy socket PHP 7.4, np. fastcgi_pass unix:/tmp/php-cgi-74.sock; (sprawdź w aaPanel → PHP 7.4 lub /tmp). Testuj nginx -t && /etc/init.d/nginx reload. Dodatkowo: nie twórz dodatknego server {} poza przeznaczonym polem; jeżeli chcesz przekierować www → non-www użyj oddzielnego bloku server z return 301. Po wdrożeniu wrzuć prosty test.php i sprawdź zmienne: HTTPS=on, SCRIPT_NAME oraz PATH_INFO, aby potwierdzić poprawną konfigurację.