Sklep, który przez dwa lata działał bez zarzutu, potrafi stanąć w środku kampanii reklamowej. Zwykle nie dzieje się to bez powodu i prawie nigdy nie jest to „przypadek”. Poniżej dziesięć awarii, które w sklepach PrestaShop powtarzają się najczęściej, z opisem tego, co je zwykle wywołuje i co można sprawdzić samodzielnie, zanim zrobi się z tego kilkudniowy przestój.
Kolejność nie jest przypadkowa. Zaczynamy od problemów, które kosztują najwięcej, czyli takich, które uderzają bezpośrednio w sprzedaż.
1. Klient nie może złożyć zamówienia
Najdroższa awaria ze wszystkich, bo najczęściej przebiega w ciszy. Sklep wygląda normalnie, produkty się wyświetlają, koszyk działa, a mimo to zamówienia przestają spływać. Właściciel orientuje się dopiero po kilku godzinach, czasem po dniu.
Dlaczego tak się dzieje
- aktualizacja modułu płatności, która nie dogaduje się z wersją sklepu
- zmiana w regulaminie lub polach formularza, przez którą jeden z kroków przestaje przechodzić dalej
- błąd w module dostawy, który nie potrafi policzyć kosztu przesyłki i blokuje przycisk
- zbyt agresywna wtyczka do zgód i ciasteczek, która blokuje skrypty potrzebne w kasie
- nowy skrypt marketingowy wklejony do szablonu, który wywala się na urządzeniach mobilnych
Jeżeli sprzedaż nagle spada do zera, a ruch w statystykach jest normalny, to prawie zawsze jest awaria kasy, a nie „słabszy dzień”.
Co zrobić od razu: przejść całą ścieżkę zakupową samodzielnie, na telefonie i w trybie prywatnym przeglądarki, wybierając różne metody dostawy i płatności. Awaria często dotyczy tylko jednej kombinacji, na przykład płatności za pobraniem przy odbiorze w punkcie.
2. Zamówienia utykają w statusie „Oczekiwanie na płatność”
Klient zapłacił, ma potwierdzenie z banku, a w panelu sklepu zamówienie wisi jako nieopłacone. Magazyn nie wysyła, klient dzwoni zdenerwowany, a przy większej liczbie zamówień robi się z tego poważny bałagan.
Dlaczego tak się dzieje
- operator płatności wysyła potwierdzenie transakcji na adres sklepu, ale zabezpieczenia serwera blokują to połączenie
- po zmianie hostingu lub certyfikatu adres powiadomień w panelu operatora został stary
- moduł płatności nie został zaktualizowany po zmianie po stronie banku
- sklep był chwilowo niedostępny w momencie, w którym przyszło potwierdzenie, i nikt tego nie powtórzył
To akurat problem, który da się wyeliminować raz a dobrze. Poprawnie skonfigurowane powiadomienia i mechanizm ponawiania sprawiają, że temat znika na stałe.
3. Sklep działa wolno
Strona główna ładuje się cztery sekundy, lista produktów po założeniu filtra jeszcze dłużej, a panel administracyjny zamiera przy zapisywaniu produktu. Klienci nie piszą reklamacji, po prostu wychodzą.
Dlaczego tak się dzieje
- tryb deweloperski zostawiony włączony po pracach programistycznych, co potrafi spowolnić sklep kilkukrotnie
- wyłączona pamięć podręczna albo ustawienie wymuszające ciągłe przebudowywanie szablonu
- filtry produktów działające na dużym katalogu bez odpowiedniego przygotowania bazy
- zdjęcia wgrywane w oryginalnej rozdzielczości z aparatu, po kilka megabajtów każde
- kilkanaście modułów, z których połowa nie jest już używana, ale nadal dokłada swoje zapytania do każdej podstrony
- współdzielony hosting, który po prostu nie nadaje się pod sklep tej wielkości
Warto zaznaczyć jedno: „sklep muli” nie zawsze oznacza, że trzeba go przepisywać. W większości przypadków, które widziałem, wystarczyło uporządkowanie ustawień, wyczyszczenie nieużywanych modułów i przeniesienie na serwer przygotowany pod PrestaShop. Efekt bywa widoczny tego samego dnia.
4. Biały ekran po instalacji modułu
Klasyk, który zna każdy, kto sam próbował rozbudować sklep. Instalacja jednego modułu, odświeżenie strony i zamiast sklepu pusta biała plansza. Czasem tylko w panelu, czasem w całym sklepie.
Dlaczego tak się dzieje
- dwa moduły próbują modyfikować ten sam element sklepu i wchodzą sobie w drogę
- moduł kupiony na marketplace został napisany pod starszą wersję PrestaShop i nie działa na obecnej
- moduł wymaga innej wersji PHP niż ta, którą ma serwer
- instalacja przerwała się w połowie i zostawiła sklep w niespójnym stanie
Dobra wiadomość jest taka, że biały ekran wygląda groźniej, niż jest. Sklep prawie zawsze da się przywrócić w kilkanaście minut, o ile ktoś wie, gdzie szukać. Zła wiadomość: próby naprawy metodą prób i błędów potrafią pogłębić problem, zwłaszcza jeśli w międzyczasie ktoś zacznie kasować pliki.
Zanim zainstalujesz cokolwiek na działającym sklepie, zrób kopię zapasową plików i bazy. To trzy minuty pracy, które ratują cały weekend.
5. Aktualizacja PrestaShop wywraca sklep
Przejście z wersji 1.7 na 8, a potem na 9, to nie jest kliknięcie przycisku. To migracja, w której zmieniają się fundamenty sklepu, wymagania serwera i sposób działania szablonu.
Dlaczego tak się dzieje
- szablon kupiony kilka lat temu nie ma wersji zgodnej z nowym PrestaShop
- część modułów nie doczekała się aktualizacji, a bez nich sklep traci kluczowe funkcje
- indywidualne modyfikacje robione kiedyś „na szybko” nie przechodzą na nową wersję
- serwer ma za starą wersję PHP albo bazy danych
- aktualizację uruchomiono bezpośrednio na sklepie produkcyjnym, bez wcześniejszego testu na kopii
Aktualizacja robiona po kolei, na kopii sklepu, z listą modułów sprawdzoną wcześniej, jest nudna i przewidywalna. Aktualizacja robiona w piątek po południu na żywym sklepie potrafi zamknąć sprzedaż na kilka dni. Jeśli planujesz przejście na nowszą wersję, warto to zaplanować ze wsparciem technicznym, zamiast ratować sytuację po fakcie.
6. Maile z zamówieniami nie docierają do klientów
Klient składa zamówienie i nie dostaje potwierdzenia. Albo dostaje, ale w folderze spam. Sklep działa poprawnie, więc problem długo pozostaje niezauważony, a w tle rosną koszty obsługi klienta.
Dlaczego tak się dzieje
- sklep wysyła maile bezpośrednio z serwera, bez uwierzytelnienia, a duzi dostawcy poczty od dwóch lat traktują takie wiadomości bardzo podejrzliwie
- brakuje wpisów w konfiguracji domeny, które potwierdzają, że sklep ma prawo wysyłać pocztę w Twoim imieniu
- adres nadawcy jest ustawiony na inną domenę niż sklep
- szablony wiadomości zostały uszkodzone przy aktualizacji
- skrzynka wysyłkowa przekroczyła limit dzienny hostingu
Sprawdzenie zajmuje chwilę: złóż zamówienie testowe na adres w Gmailu i na adres w innej poczcie. Jeżeli w jednej skrzynce mail jest, a w drugiej nie, problem prawie na pewno leży w konfiguracji domeny.
7. Stany magazynowe rozjeżdżają się z integracjami
Sklep pokazuje pięć sztuk, w magazynie jest zero. Albo odwrotnie: towar leży na półce, a sklep twierdzi, że jest niedostępny. Przy sprzedaży wielokanałowej, z Allegro i systemem do obsługi zamówień w tle, to jeden z najczęstszych powodów reklamacji.
Dlaczego tak się dzieje
- synchronizacja przestała się uruchamiać, bo zadanie automatyczne zostało wyłączone przy zmianie serwera
- ten sam produkt istnieje w sklepie w dwóch wersjach po nieudanym imporcie i integracja aktualizuje niewłaściwą
- warianty produktu mają zdublowane lub puste kody, więc system nie wie, co z czym połączyć
- hurtownia zmieniła format pliku z danymi i import cicho przestał działać
- przy dużej sprzedaży w krótkim czasie synchronizacja nie nadąża i dochodzi do nadsprzedaży
To rzadko jest awaria jednego systemu. Zwykle jest to kwestia tego, że nikt nie pilnuje, czy wymiana danych między sklepem a resztą narzędzi faktycznie się odbywa. Prosty monitoring rozwiązuje większość takich sytuacji, zanim zauważy je klient.
8. Sklep zostaje zaatakowany
Objawy bywają nieoczywiste. W wynikach Google przy nazwie sklepu pojawiają się dziwne podstrony z hasłami, których nigdy nie było w ofercie. Część użytkowników z telefonu jest przekierowywana na obcą stronę. Google Search Console wysyła ostrzeżenie. Sprzedaż spada, choć w panelu wszystko wygląda normalnie.
Dlaczego tak się dzieje
- sklep od dłuższego czasu nie był aktualizowany, a znane luki są publikowane i szybko wykorzystywane masowo
- na serwerze stoi kilka stron i włamanie do jednej otworzyło drogę do pozostałych
- hasło do panelu było proste albo krążyło w mailach
- zainstalowano moduł z niepewnego źródła, na przykład „darmową” wersję płatnego rozszerzenia
Samo usunięcie podejrzanych plików to nie jest naprawa. Jeżeli nie zamknie się furtki, przez którą ktoś wszedł, wróci w ciągu kilku dni.
Przy podejrzeniu włamania kolejność ma znaczenie: najpierw zabezpieczenie kopii i dostępów, potem znalezienie źródła, na końcu sprzątanie i zgłoszenie do Google. Odwrotna kolejność kończy się powtórką za tydzień.
9. Sklep pada przy większym ruchu
Kampania rusza, wchodzi kilkuset użytkowników naraz i sklep przestaje odpowiadać. Paradoksalnie awaria pojawia się dokładnie w tym momencie, w którym najbardziej zależy nam na sprzedaży, czyli przy Black Friday, przy premierze kolekcji albo po wzmiance u influencera.
Dlaczego tak się dzieje
- serwer jest dobrany pod średni ruch, a nie pod szczyt
- brak pamięci podręcznej sprawia, że każdy użytkownik wymusza pełne przeliczenie strony
- promocje i rabaty liczone dla każdego koszyka osobno potrafią mocno obciążyć bazę
- nikt nie sprawdził wcześniej, ile sklep faktycznie wytrzyma
Ruch reklamowy da się przewidzieć, więc da się też przygotować sklep zawczasu. Przegląd na tydzień przed kampanią kosztuje ułamek tego, co stracona sprzedaż w dniu premiery.
10. Produkty są w panelu, ale nie widać ich w sklepie
Produkt dodany, opisany, ze zdjęciami, a mimo to nie pojawia się w kategorii ani w wyszukiwarce. Albo pojawia się, ale filtry go pomijają.
Dlaczego tak się dzieje
- produkt nie ma przypisanej kategorii domyślnej albo nie jest powiązany z żadnym sklepem w konfiguracji
- indeks wyszukiwarki nie został przebudowany po masowym imporcie
- ustawiona data dostępności w przyszłości lub wyłączona sprzedaż przy braku stanu
- filtry mają zapisane stare wartości i nie widzą nowych cech produktów
- pamięć podręczna trzyma starą wersję strony kategorii
To akurat problem, który najczęściej rozwiązuje się w kilka minut. Warunek jest jeden: trzeba wiedzieć, w której z tych pięciu rzeczy leży przyczyna, zamiast klikać po kolei w ustawieniach.
Co łączy wszystkie te awarie
Prawie żadna z nich nie bierze się z tego, że PrestaShop jest zły. Biorą się z trzech rzeczy, które powtarzają się w niemal każdym sklepie, do którego jestem wzywany:
- brak kopii zapasowej, przez co drobna awaria zmienia się w kryzys
- zmiany wprowadzane od razu na działającym sklepie, bez wcześniejszego sprawdzenia na kopii
- brak kogokolwiek, kto regularnie patrzy na sklep, więc problemy wychodzą dopiero wtedy, gdy zauważy je klient
Sklep internetowy to nie strona wizytówkowa. Działa non stop, przyjmuje pieniądze i dane klientów, integruje się z kilkoma systemami naraz. Traktowanie go jak czegoś, co „po prostu stoi”, wcześniej czy później kończy się telefonem w niedzielę wieczorem.
Prosta lista kontrolna dla właściciela sklepu
- Czy masz automatyczną kopię zapasową plików i bazy i czy ktoś kiedykolwiek sprawdził, że da się z niej odtworzyć sklep?
- Czy wiesz, jaką wersję PrestaShop i PHP ma Twój sklep?
- Czy raz w tygodniu ktoś składa zamówienie testowe, przechodząc pełną ścieżkę zakupową?
- Czy dostajesz powiadomienie, gdy sklep przestaje odpowiadać, zanim napisze o tym klient?
- Czy moduły, których już nie używasz, zostały odinstalowane, a nie tylko wyłączone?
- Czy masz jedną osobę, która odpowiada za techniczną stronę sklepu i którą możesz zwyczajnie zadzwonić?
Jeżeli przy trzech lub więcej punktach odpowiedź brzmi „nie wiem”, to nie jest kwestia tego, czy coś się wydarzy, tylko kiedy.
Kiedy warto oddać temat komuś z zewnątrz
Część rzeczy z tej listy da się ogarnąć samodzielnie i to zupełnie sensowne podejście. Są jednak trzy sytuacje, w których samodzielne próby zwykle kosztują więcej, niż oszczędzają:
- Sklep nie przyjmuje zamówień. Każda godzina to konkretna, policzalna strata.
- Podejrzenie włamania. Tu liczy się nie tylko usunięcie skutków, ale zamknięcie przyczyny.
- Aktualizacja lub migracja. Znacznie taniej jest zaplanować ją z kimś, kto robił to wielokrotnie, niż ratować sklep po nieudanej próbie.
Zajmuję się wsparciem technicznym sklepów PrestaShop od strony praktycznej: naprawą awarii, optymalizacją wydajności, aktualizacjami i bieżącą opieką nad sklepem. Bez systemu zgłoszeń i bez przerzucania tematu między konsultantami, z bezpośrednim kontaktem z osobą, która faktycznie pracuje przy Twoim sklepie.
Jeśli coś z powyższej listy brzmi znajomo albo chcesz po prostu, żeby ktoś raz porządnie przejrzał sklep, zanim zrobi się gorąco, napisz lub zadzwoń.
Najczęstsze pytania
Ile trwa naprawa sklepu, który nie przyjmuje zamówień?
Sama diagnoza to zwykle od kilkunastu minut do godziny. Naprawa zależy od przyczyny, ale w większości przypadków sklep wraca do sprzedaży tego samego dnia. Najdłużej trwają sytuacje, w których wcześniej ktoś próbował naprawiać na własną rękę i zdążył zmienić wiele rzeczy naraz.
Czy da się naprawić sklep bez dostępu do serwera?
Do części rzeczy wystarczy dostęp do panelu administracyjnego, ale poważniejsze awarie wymagają wglądu w logi i pliki na serwerze. Bez tego pracuje się po omacku i wydłuża czas naprawy.
Czy warto aktualizować sklep, skoro obecna wersja działa?
Warto, choć nie w pośpiechu. Stare wersje przestają dostawać poprawki bezpieczeństwa, a im dłużej odkłada się aktualizację, tym większy i droższy staje się skok. Rozsądny plan to aktualizacja zaplanowana w spokojnym okresie sprzedażowym, przetestowana wcześniej na kopii sklepu.
Sklep zamula. Czy to znaczy, że trzeba go zbudować od nowa?
Prawie nigdy. W większości przypadków przyczyną są ustawienia, nadmiar modułów, nieprzygotowane zdjęcia lub niedopasowany serwer. Przebudowa sklepu to ostateczność, a nie punkt wyjścia.
