Zgłoś problem - opinie klientów o kartach produktów, zgłoszenia zepsutych linków i błędnych cen z panelem w back office

Twoi klienci znajdują błędne strony szybciej niż Ty

Każdy katalog z czasem się rozjeżdża. Link do dostawcy przestaje działać, cena została z poprzedniego sezonu, a w opisie brakuje akurat tego jednego szczegółu, którego kupujący naprawdę potrzebuje. Ludźmi, którzy to zauważają, są Twoi odwiedzający — i jeśli nie dasz im sposobu, by Ci o tym powiedzieli, po prostu wyjdą.

Ten moduł umieszcza na każdej karcie produktu dyskretny przycisk Zgłoś problem. Jedno kliknięcie otwiera okno dialogowe, odwiedzający jednym zdaniem opisuje, co jest nie tak, a zgłoszenie ląduje w Twoim back office.

Cztery rodzaje problemów i jedno zdanie

Odwiedzający wybiera spośród opcji zepsuty link, błędna cena, brak informacji i inne — to Ty decydujesz, które z czterech udostępnić — po czym pisze krótki opis o długości od 10 do 1000 znaków, z licznikiem aktualizowanym na żywo podczas pisania.

Imię i adres e-mail są opcjonalne i pokazują się wyłącznie gościom; zalogowani klienci są rozpoznawani po swoim koncie. Adres e-mail służy dokładnie jednemu celowi: poinformowaniu zgłaszającego, że problem został naprawiony.

Najpierw zapis, potem e-mail — i o to właśnie chodzi

Zgłoszenie trafia do Twojej bazy danych, zanim moduł w ogóle spróbuje wysłać jakąkolwiek wiadomość. Jeśli Twój serwer pocztowy ma gorszy dzień, zgłoszenie i tak jest na liście. Błąd trafia do logów, zamiast wyświetlić się odwiedzającemu jako komunikat o niepowodzeniu.

Ta kolejność jest powodem, dla którego powstała wersja 4. Więcej o tym poniżej.

Back office, które jest prawdziwym procesem pracy

Zgłoszenia trafiają na listę, którą da się realnie przerobić. Filtruj według statusu, rodzaju problemu, kategorii i zakresu dat oraz pełnotekstowo po treści wiadomości, imieniu i adresie e-mail. Zaznacz kilka i jedną akcją oznacz je jako w toku, rozwiązane, spam lub usuń.

Każdy wiersz rozwija się, pokazując pełną treść wiadomości, produkt — wraz z odnośnikami zarówno do jego strony w sklepie, jak i do edytora — zgłaszającego, znaczniki czasu, wybór statusu oraz pole notatki na Twoją odpowiedź. Zgłoszenia przechodzą przez statusy otwarte, w toku, rozwiązane, duplikat i spam.

Eksport do CSV daje dokładnie to, co pasuje do aktualnie ustawionych filtrów, a nie całą tabelę.

Liczby, które pokazują, gdzie są problemy

Panel W skrócie zlicza to, co czeka na obsługę, co wpłynęło w tym tygodniu i w tym miesiącu, co udało się rozwiązać i co było spamem — każdą liczbę można kliknąć i przejść prosto do przefiltrowanej listy. Obok znajduje się pięć najczęściej zgłaszanych produktów, co zwykle jest najszybszą drogą do strony, która naprawdę wymaga poprawki.

Widżet na stronie głównej Dashboardu pokazuje liczbę oczekujących zgłoszeń i całkowicie się ukrywa, gdy nie ma żadnego.

Powiedz zgłaszającemu, że problem jest naprawiony

Gdy ustawisz zgłoszenie na Rozwiązane, jedno pole wyboru wysyła wiadomość do osoby, która je złożyła. Wysyłka nastąpi tylko wtedy, gdy zostawiła adres, a Twoja notatka trafia do treści wiadomości. Nic to nie kosztuje, a to właśnie ten element klienci zapamiętują.

Ochrona przed spamem, która nie karze prawdziwych ludzi

Pole honeypot, minimalny czas wypełnienia i podpisany algorytmem HMAC token o ograniczonej ważności działają zawsze i nie wymagają żadnej konfiguracji. Token jest ważny dwie godziny i jest powiązany z produktem, więc nie da się go odtworzyć na innych pozycjach w katalogu.

Do tego dochodzi godzinny limit na odwiedzającego i produkt (domyślnie 1, wartość 0 wyłącza go), a nad nim stały globalny limit 10 zgłoszeń na godzinę na odwiedzającego. Wykrywanie duplikatów sprawia, że to samo zgłoszenie tej samej osoby dotyczące tego samego produktu w ciągu 24 godzin zostaje zapisane jako Duplikat, zamiast powiadamiać Cię dwa razy — wszystkie i tak pozostają na liście.

Opcjonalna reCAPTCHA v3 jest dostępna i domyślnie wyłączona. Ładuje ona kod Google na Twoich kartach produktów, więc jeśli ją włączysz, wspomnij o tym w polityce prywatności.

Adres IP zgłaszającego nigdy nie jest zapisywany

Ograniczanie liczby zgłoszeń musi rozpoznawać powracającego odwiedzającego, dlatego moduł zapisuje hash_hmac('sha256', $ip, _COOKIE_KEY_) — skrót kluczowany własnym sekretem Twojego sklepu — a nigdy sam adres.

Kluczowanie ma tu znaczenie. Niekluczowany skrót SHA-256 adresu IP można odwrócić w kilka minut, przeliczając wszystkie cztery miliardy adresów IPv4; kluczowany sekretem, który zna wyłącznie Twój sklep, jest na to odporny. Własny zestaw testów modułu sprawdza to wprost.

Zgłoszenia są usuwane razem z produktem, którego dotyczą, a wszystkie razem przy odinstalowaniu modułu. Jeśli oficjalny moduł RODO psgdpr jest zainstalowany i włączony, jego blok zgody jest automatycznie wyświetlany w formularzu.

Wersja 4 naprawiła moduł, który nie dostarczył ani jednego zgłoszenia od 3.1.0

Warto to powiedzieć wprost, bo to jest prawdziwy powód do aktualizacji.

Gdy w wersji 3.1.0 punkt odbioru zgłoszeń przeniósł się do controllers/front/, leżąca obok niego ścieżka do szablonu wiadomości nie została zaktualizowana, więc wskazywała na katalog, który nie istnieje. Mail::Send() zwracało false, moduł odpowiadał die('0') — a ponieważ 0 jest poprawnym JSON-em, front-end je parsował i uruchamiał procedurę sukcesu.

Każdy sklep na wersjach od 3.1.0 do 3.2.2 wyrzucał zgłoszenia klientów, dziękując im jednocześnie za ich przesłanie. Cztery wydane wersje, i nic nie było zapisywane, więc nie było czego odzyskiwać. Ścieżki do szablonów wiadomości są teraz rozwiązywane z _PS_MODULE_DIR_, a zapis następuje przed wysyłką.

Zamknęła też otwarty przekaźnik pocztowy

Wersja 3.x odczytywała adresata powiadomienia z ukrytego pola na stronie. Nigdy nie był on walidowany ani porównywany z własnym adresem sklepu, po czym trafiał prosto do Mail::Send().

Dowolny anonimowy odwiedzający mógł zmusić Twój sklep do wysyłania wiadomości na dowolny wybrany przez siebie adres, z nieescapowanym kodem HTML w treści i tak często, jak tylko chciał. Na koszt reputacji Twojego nadawcy. Adresat pochodzi teraz z konfiguracji modułu i znikąd indziej.

secure_key, który miał temu zapobiegać, miał postać md5(_COOKIE_KEY_ . 'reportbrokenlink') — stały przez całe życie sklepu i wypisywany na każdą kartę produktu. Odczytany raz, użyteczny na zawsze. Dziś jest to token podpisany algorytmem HMAC, ograniczony czasowo i powiązany z produktem.

Dane wprowadzone przez odwiedzającego są też escapowane na wyjściu, a nie tylko filtrowane na wejściu. PrestaShop podstawia zmienne w wiadomościach zwykłym str_replace i nie escapuje niczego, więc nieescapowany ciąg znaków pozwoliłby zgłaszającemu umieścić link phishingowy w wiadomości, która naprawdę pochodzi z Twojego sklepu.

Front-end pozbył się jQuery 1.8.2 i wszystkich pozostałych zależności

Wersja 3.x ładowała jQuery 1.8.2 z CDN Google na każdej karcie produktu. To wysyłało adres IP każdego odwiedzającego do Google jeszcze przed jakąkolwiek zgodą, dostarczało bibliotekę z 2012 roku z czterema opublikowanymi ostrzeżeniami bezpieczeństwa i nadpisywało jQuery Twojego szablonu dla wszystkiego, co uruchamiało się później.

To wszystko zniknęło. Front-end to czysty JavaScript i CSS bez żadnych zależności — po jednym małym pliku, rejestrowanym wyłącznie na kartach produktów. Bez jQuery, bez Bootstrapa.

Zgłoszenia są teraz wysyłane metodą POST. Wersja 3.x wysyłała je metodą GET — przez opcję post: "POST", której jQuery w ogóle nie ma, więc po cichu używana była wartość domyślna — co powodowało, że adres e-mail każdego zgłaszającego trafiał do logów dostępu Twojego serwera.

Dostępne, bo tak zostało zbudowane

Okno dialogowe jest prawdziwym oknem dialogowym: fokus przenosi się do środka, klawisz Tab jest w nim uwięziony, Escape je zamyka, a fokus wraca na przycisk, z którego przyszedłeś. Błędy są ogłaszane czytnikom ekranu, obramowania fokusu są widoczne, prefers-reduced-motion jest respektowane, a poniżej 480 px okno przechodzi w tryb pełnoekranowy.

Przy otwarciu jest ono ponadto przenoszone do <body>. Renderowane w miejscu, lądowało wewnątrz formularza <form> dodawania do koszyka z Twojego szablonu — zagnieżdżony formularz, który psuł układ strony i mógł wysłać coś zupełnie innego.

Kompatybilność

PrestaShop 1.7 do 9, PHP 7.2 do 8.3, w ośmiu językach: angielskim, francuskim, hiszpańskim, holenderskim, niemieckim, polskim, tureckim i włoskim. Jako polskojęzyczny sprzedawca pracujesz więc w przetłumaczonym back office.

Bez nadpisań, bez modyfikacji rdzenia i szablonu, bez jQuery. Pięć hooków, jedna tabela w bazie danych. Odinstalowanie usuwa tabelę, każde zapisane zgłoszenie i wszystkie ustawienia — jeśli chcesz je zachować, najpierw wyeksportuj je do CSV.

Najczęściej zadawane pytania

Czy moi klienci muszą mieć konto, żeby coś zgłosić?

Nie, a pozostawienie zgłoszeń od gości włączonych jest zalecane — to zwykle właśnie goście zauważają błędną stronę. Jeśli wolisz, jednym ustawieniem ograniczysz przycisk do zalogowanych klientów.

Gdzie pojawia się przycisk?

Na kartach produktów, albo obok informacji o produkcie, albo pod nimi — displayProductAdditionalInfo (obok informacji o produkcie) lub displayFooterProduct (w stopce karty produktu). Jeśli Twój szablon ukrywa jeden z nich, przełącz się na drugi w ustawieniach modułu.

Co się stanie, jeśli mój serwer pocztowy zawiedzie?

Nic nie ginie. Zgłoszenie jest zapisywane, zanim moduł spróbuje cokolwiek wysłać, błąd trafia do Zaawansowane → Logi, a zgłoszenie czeka na Twojej liście. To największa różnica względem wersji 3.

Czy adresy IP zgłaszających są zapisywane?

Nie. Ograniczanie liczby zgłoszeń używa skrótu SHA-256 kluczowanego własnym sekretem Twojego sklepu, nigdy samego adresu. Imię i adres e-mail są opcjonalne i zbierane wyłącznie po to, byś mógł poinformować zgłaszającego o naprawie.

Odwiedzający mówi, że formularz poinformował go o wygaśnięciu.

Podpisany token jest ważny dwie godziny, więc zobaczy to ktoś, kto zostawił kartę produktu otwartą dłużej. Wystarczy odświeżyć stronę. Tokeny są powiązane z produktem i właśnie to uniemożliwia ich ponowne użycie gdzie indziej w Twoim katalogu.

Dlaczego niektóre zgłoszenia są oznaczone jako Duplikat i nie przychodzą do mnie e-mailem?

Wykrywanie duplikatów jest domyślnie włączone: ta sama osoba, ten sam produkt i ten sam rodzaj problemu w ciągu 24 godzin są zapisywane jako duplikat, zamiast powiadamiać Cię dwa razy. Wszystkie i tak pozostają na liście — przefiltruj po statusie Duplikat albo wyłącz to ustawienie.

Czy mogę wyciągnąć zgłoszenia z PrestaShop?

Tak. Eksport do CSV daje dokładnie to, co pasuje do Twoich aktualnych filtrów. Komórki zaczynające się od znaku, który arkusz kalkulacyjny potraktuje jako formułę (=, +, -, @, tabulatora lub powrotu karetki), są celowo neutralizowane, żeby nikt nie przemycił formuły arkusza kalkulacyjnego do pliku, który otworzysz.

Czy moduł wymaga jQuery albo Bootstrapa?

Ani jednego, ani drugiego. Front-end to czysty JavaScript i CSS, po jednym małym pliku, ładowanym wyłącznie na kartach produktów. Jeśli szukasz przyczyny kliknięcia, które nic nie robi, sprawdź w konsoli przeglądarki, czy nie ma na stronie niezwiązanego błędu innego skryptu.

Co stanie się z moimi zgłoszeniami po odinstalowaniu?

Zostaną usunięte razem ze wszystkimi ustawieniami — najpierw zostaniesz poproszony o potwierdzenie. Jeśli mogą Ci się jeszcze przydać, wcześniej wyeksportuj je do CSV.