PS PrestaShop Początkujący

Alerty błędów 500, 404 i checkoutu PrestaShop (DataFirefly Site Alerts)

Instalacja modułu, wybór odbiorców, ustawienia alertów 404 i crona, opis każdego typu alertu.

Zaktualizowano Wersja modułu 1.0.0

DataFirefly Site Alerts wysyła e-mail na wybrane adresy, gdy sklep PrestaShop 8 lub 9 zwraca błąd 500, gromadzi błędy 404 albo gdy klient dochodzi do etapu zamówienia, na którym nie jest oferowany żaden przewoźnik lub żadna metoda płatności. Ta dokumentacja opisuje instalację, ustawienia, zawartość każdego alertu i rozwiązywanie problemów.

Instalacja

  1. W panelu administracyjnym otwórz Moduły > Menedżer modułów, kliknij Załaduj moduł i prześlij plik dfsitealerts-1.0.0.zip.
  2. Moduł tworzy swoją tabelę i zakładkę Zaawansowane > Alerty błędów i checkoutu. Przycisk Konfiguruj modułu prowadzi do niej bezpośrednio.
  3. Podczas instalacji adres e-mail sklepu zostaje ustawiony jako odbiorca, a cztery rodzaje wykrywania są aktywne.
  4. Kliknij Wyślij testowy e-mail, aby sprawdzić, czy alerty docierają.

Moduł jest zgodny z PrestaShop od 8.0 do 9.x oraz z trybem multisklepu. Nie korzysta z żadnych zależności Composer. E-maile są wysyłane zgodnie z konfiguracją w Zaawansowane > E-mail: jeśli e-maile są tam wyłączone, u góry strony modułu wyświetla się ostrzeżenie.

Pulpit

U góry strony wyświetla się liczba różnych problemów wykrytych w ciągu ostatnich 24 godzin, według typu: błąd 500, błąd 404, brak przewoźnika, brak metody płatności, strona niedostępna. Ten sam URL lub ten sam błąd jest liczony tylko raz. Poniżej znajdują się aktualni odbiorcy, URL crona oraz przyciski Wyślij testowy e-mail, Uruchom zadanie zaplanowane teraz i Wyczyść dziennik.

Odbiorcy

  • Adresy e-mail: jeden adres w wierszu (akceptowane są też przecinki i średniki). Każdy adres otrzymuje osobny e-mail. Nieprawidłowy adres zostaje odrzucony przy zapisie.
  • Język alertów: język e-maili, niezależny od języka odwiedzających. Domyślnie jest to domyślny język sklepu.

Co wywołuje alert

Każdy rodzaj wykrywania można włączyć lub wyłączyć osobno.

Błędy serwera (500)

Na końcu żądania na froncie sklepu moduł przechwytuje błędy krytyczne PHP, nieprzechwycone wyjątki i każdą stronę, która odpowiada statusem 5xx. Tryb konserwacji (503) jest pomijany. E-mail zawiera:

  • komunikat błędu i stos wywołań, z usuniętą ścieżką serwera;
  • typ błędu PHP, plik i wiersz jako ścieżkę względną;
  • URL, stronę źródłową, metodę HTTP, kontroler i user agent;
  • szczytowe użycie pamięci oraz wersje PrestaShop i PHP.

Gdy PrestaShop przechwytuje PrestaShopException i wyświetla swoją stronę błędu, komunikat PHP nie jest dostępny: moduł pobiera wtedy ostatni wpis z dzisiejszego pliku var/logs/RRRRMMDD_exception.log. Identyczne błędy są grupowane, a zmienne liczby (identyfikatory, rozmiary pamięci) są przy grupowaniu pomijane.

Nie znaleziono stron (404)

Błędy 404 są grupowane według ścieżki URL. Parametry identyfikujące stronę (controller, id_product…) są zachowywane, a parametry śledzenia (utm_*, gclid, fbclid, msclkid…) są pomijane. Alert jest wysyłany zgodnie z ustawieniami opisanymi w następnej sekcji.

Zamówienie bez przewoźnika

Wykrywanie działa, gdy klient dochodzi do etapu dostawy z adresem dostawy oraz niepustym i niewirtualnym koszykiem, a nie jest mu oferowany żaden przewoźnik. Problemy są grupowane według kraju i województwa/stanu. E-mail zawiera:

  • ID koszyka i klienta, kraj, województwo/stan, kod pocztowy i strefę;
  • wagę i sumę koszyka, listę produktów i grupę klienta;
  • Aktywni przewoźnicy dla tej strefy i grupy, z podaniem dla każdego z nich powodu jego braku: poza przedziałami wagowymi, poza przedziałami cenowymi, zbyt duży rozmiar paczki, wykluczony przez ograniczenia produktów lub podział paczek albo niezwrócony dla tego koszyka (moduł przewoźnika lub koszty wysyłki niedostępne);
  • Produkty ograniczone do wybranych przewoźników: produkty w koszyku, które mają wybranych przewoźników w zakładce Wysyłka.

Jeśli do strefy i grupy klienta nie przypisano żadnego aktywnego przewoźnika, alert informuje o tym bezpośrednio.

Zamówienie bez metody płatności

Wykrywanie działa, gdy klient dochodzi do etapu płatności z koszykiem do zapłaty, a żaden moduł płatności nie oferuje żadnej opcji. Darmowy koszyk (suma 0) nie jest brany pod uwagę. Problemy są grupowane według kraju, waluty, przewoźnika i grupy. E-mail zawiera kraj, walutę, wybranego przewoźnika, sumę, grupę klienta, a następnie:

  • Aktywne moduły płatności: wszystkie zainstalowane i włączone moduły płatności;
  • Moduły płatności dozwolone dla tego kraju, waluty, grupy i przewoźnika: te, które ograniczenia w Płatność > Preferencje dopuszczają dla tego klienta.

Jeśli druga lista jest pusta, przyczyna leży w ograniczeniach. Jeśli zawiera moduły, są one dozwolone, ale nie zwróciły żadnej opcji: przyczyna leży w ich własnej konfiguracji (minimalna kwota, niepołączone konto, tryb testowy).

Ustawienia 404

  • Próg alertu: alert jest wysyłany, gdy ten sam URL osiągnie tę liczbę wizyt od ostatniego alertu. Domyślnie 5, wartość 1 oznacza alert już przy pierwszej wizycie.
  • Natychmiastowy alert dla uszkodzonych linków wewnętrznych: gdy strona źródłowa należy do sklepu, alert jest wysyłany przy pierwszej wizycie, niezależnie od progu.
  • Pomijaj boty: wyszukiwarki, crawlery SEO, skrypty i puste user agenty.
  • Pomijaj pliki statyczne: obrazy, CSS, JS, czcionki i filmy.
  • Pomijane adresy URL: jedna ścieżka w wierszu, * oznacza dowolny ciąg znaków. Domyślna lista pomija typowe skany: /wp-*, /wordpress/*, /xmlrpc.php, */.env, */.git/*, /cgi-bin/*, *phpmyadmin*, /.well-known/*, /apple-touch-icon*.

Limity wysyłki i dzienne podsumowanie

  • Odstęp między dwoma alertami dla tego samego problemu: domyślnie 60 minut. Wystąpienia w tym czasie są zliczane i podawane w następnym alercie, w wierszu „Wystąpienia od ostatniego alertu”.
  • Maksymalna liczba alertów na godzinę: domyślnie 20, 0 oznacza brak limitu. Problemy powyżej limitu pozostają zarejestrowane i pojawiają się w podsumowaniu.
  • Dzienne podsumowanie: jeden e-mail dziennie o wybranej godzinie (domyślnie 8:00), który wymienia każdy problem zarejestrowany od poprzedniego podsumowania, w tym te poniżej progu alertu. Nie jest wysyłany, jeśli nic się nie wydarzyło.
  • Przechowuj dziennik przez: domyślnie 30 dni, od 1 do 365.

Zadanie zaplanowane

Alerty 500, 404 i alerty dotyczące zamówienia są wysyłane w czasie rzeczywistym. Zadanie zaplanowane wysyła dzienne podsumowanie o zaplanowanej godzinie, ponownie przetwarza alerty, których nie udało się zapisać w bazie, czyści dziennik i uruchamia kontrolę dostępności. Wystarczy uruchamianie co 15 minut.

Cron przez URL

*/15 * * * * curl -fsS "https://twoj-sklep.pl/module/dfsitealerts/cron?token=…" > /dev/null

Dokładny URL z tokenem jest wyświetlany na stronie modułu wraz z przyciskiem Kopiuj. Odpowiada w formacie JSON i działa również w trybie konserwacji. Nieprawidłowy token zwraca błąd 403.

Cron z wiersza poleceń

*/15 * * * * php /sciezka/do/prestashop/modules/dfsitealerts/cron.php > /dev/null

Polecenie obsługuje wszystkie aktywne sklepy w trybie multisklepu.

Bez crona

Po zwykłej wizycie w sklepie moduł uruchamia konserwację najwyżej raz na 15 minut. Podsumowanie jest więc wysyłane po pierwszej wizycie następującej po zaplanowanej godzinie. Kontrola dostępności nie działa w tym trybie.

Kontrola dostępności

Niektóre błędy 500 występują przed uruchomieniem PrestaShop (awaria PHP-FPM, uszkodzony plik konfiguracyjny): żaden moduł nie może ich wtedy przechwycić. Kontrola dostępności przy każdym uruchomieniu crona pobiera z serwera adresy URL wymienione w polu Adresy URL do testowania (maksymalnie 10, strona główna, jeśli lista jest pusta). Odpowiedź 5xx lub brak połączenia wywołuje alert Kontrola dostępności nie powiodła się z kodem HTTP, czasem odpowiedzi i błędem połączenia. Kod 503 jest pomijany, gdy sklep jest w trybie konserwacji.

Dodaj stronę kategorii i stronę produktu, aby uzyskać lepsze pokrycie. Na wypadek całkowitej awarii serwera, która uniemożliwia też działanie crona, używaj dodatkowo zewnętrznej usługi monitorowania dostępności.

Dziennik alertów

Lista na dole strony pokazuje każdy zarejestrowany problem: typ, miejsce (URL albo kraj / waluta / przewoźnik w przypadku zamówienia), komunikat lub stronę źródłową, liczbę wystąpień, pierwsze i ostatnie wystąpienie oraz datę ostatniego alertu. Listę można filtrować według typu i eksportować do CSV. Przycisk Zobacz otwiera kartę z tą samą treścią co e-mail oraz surowymi danymi w JSON. Usunięcie wpisu zeruje jego licznik.

Dane i poufność

  • Alerty dotyczące zamówienia zawierają ID koszyka i klienta, kraj, województwo/stan, kod pocztowy, wagę i zawartość koszyka. Nie zawierają imienia i nazwiska, adresu pocztowego, adresu e-mail ani telefonu.
  • Ścieżka serwera jest usuwana z komunikatów błędów i stosów wywołań.
  • Dziennik jest czyszczony po upływie wybranego okresu przechowywania.
  • Gdy baza danych odmawia zapisu, alert jest zachowywany w pliku w var/logs (maksymalnie 2 MB) i przetwarzany ponownie przy następnym uruchomieniu konserwacji.

Znane ograniczenia

  • Monitorowany jest tylko front sklepu. Błędy w panelu administracyjnym nie wywołują alertu.
  • Całkowita awaria serwera lub PHP uniemożliwia wysłanie jakiegokolwiek e-maila: użyj zewnętrznej usługi monitorowania dostępności.
  • Wykrywanie problemów z zamówieniem opiera się na natywnym procesie zamówienia PrestaShop. Przy zewnętrznym module zamówienia na jednej stronie alert o przewoźniku zależy od wywołania hooka displayBeforeCarrier, a alert o płatności jest oceniany dopiero po wybraniu przewoźnika.
  • Wysyłka po wyświetleniu strony wymaga PHP-FPM lub LiteSpeed. Przy innym trybie uruchamiania PHP e-mail jest wysyłany przed zakończeniem żądania.

Rozwiązywanie problemów

Testowy e-mail nie dociera

Sprawdź Zaawansowane > E-mail i wyślij testowy e-mail z tej strony. Sprawdź też folder spam: dodaj adres nadawcy sklepu do kontaktów.

Otrzymuję zbyt wiele alertów 404

Podnieś Próg alertu, dodaj odpowiednie ścieżki do Pomijane adresy URL lub utwórz brakujące przekierowania 301: przekierowany URL nie zwraca już błędu 404.

Brak alertu o zamówieniu, mimo że klient zgłosił problem

Sprawdź, czy oba rodzaje wykrywania dotyczące zamówienia są aktywne i czy klient rzeczywiście dotarł do danego etapu z adresem. W przypadku zewnętrznego modułu zamówienia na jednej stronie zapoznaj się z sekcją Znane ograniczenia.

Komunikat „Zadanie cron nigdy nie zostało uruchomione.” nie znika

Otwórz URL crona w przeglądarce: powinien odpowiedzieć {"ok":true,…}. Odpowiedź invalid token oznacza, że URL został skopiowany niekompletnie.

Czy ta strona była pomocna?

Nadal utknąłeś? Napisz do wsparcia