Opieka nad sklepem PrestaShop: co robić, a czego nie ruszać

Dlaczego sklep wymaga innej opieki niż strona

PrestaShop to system znacznie bardziej złożony od typowej strony firmowej. Poza silnikiem i szablonem działa w nim zwykle kilkanaście modułów odpowiadających za płatności, przesyłki, integracje z magazynem i fakturowanie.

Każdy z nich dotyka procesu, w którym po drugiej stronie są pieniądze klienta. To zmienia hierarchię problemów: na stronie firmowej najgorsze, co się zdarza, to niedziałający formularz, a w sklepie płatność, która przechodzi, choć zamówienie nie zapisuje się w systemie.

Dlatego opieka nad sklepem obejmuje, poza aktualizacjami, regularne przechodzenie całej ścieżki zakupowej: od karty produktu, przez koszyk i dostawę, po realną płatność testową.

Kopia testowa sklepu: miejsce na każdą zmianę

Podstawą opieki nad sklepem jest kopia testowa: osobna instalacja z aktualnymi danymi, niewidoczna dla klientów i wyszukiwarki. Tam sprawdza się aktualizacje, nowe moduły i zmiany w szablonie, zanim trafią do sklepu.

Kopia musi być regularnie odświeżana. Test aktualizacji na danych sprzed roku nie wykryje problemu z produktami dodanymi w tym czasie ani z nowymi ustawieniami dostaw.

Przy kopii testowej trzeba też wyłączyć rzeczy, które mogłyby dotrzeć do prawdziwych klientów: wysyłkę wiadomości, synchronizację z systemem magazynowym i płatności w trybie produkcyjnym.

Awarie, których nie widać

Awarię, przy której sklep nie działa, widać szybko, bo klienci zaczynają dzwonić. Znacznie droższa jest ta, przy której wszystko wygląda normalnie, a zamówienia po prostu nie dochodzą.

Typowe przyczyny: wygasły klucz w module płatności, zmiana adresu powiadomień po stronie operatora, przepełniona kolejka zadań, przekroczony limit wysyłki poczty. W każdym z tych przypadków sklep po prostu przestaje dostawać zamówienia, bez żadnego komunikatu o błędzie.

Dlatego comiesięczny test zakupu realną transakcją na niską kwotę jest najważniejszą pojedynczą czynnością w całej opiece. Płatność się zwraca, a Wy wiecie, że zakup działa także po ostatnich zmianach w sklepie i u operatorów.

Test zakupu krok po kroku

Comiesięczny test zakupu ma sens tylko wtedy, gdy obejmuje całą ścieżkę, od wyszukania produktu po dokument sprzedaży. Poniżej kolejność, którą warto przejść za każdym razem.

• Wyszukanie produktu i przejście z kategorii do karty produktu
• Dodanie do koszyka, zmiana ilości i usunięcie drugiego produktu
• Wybór dostawy, w tym punktu odbioru na mapie
• Płatność realną transakcją na niską kwotę
• Sprawdzenie maila z potwierdzeniem i statusu zamówienia w panelu
• Sprawdzenie dokumentu sprzedaży i przekazania zamówienia do magazynu
• Zwrot płatności i anulowanie testowego zamówienia

Wynik testu warto zapisać w krótkim raporcie. Po kilku miesiącach widać, czy któryś krok zaczyna działać wolniej albo czy zmiany u operatora płatności wymagają reakcji.

Stare wersje: aktualizować czy przepisać

Wiele sklepów działa na wersjach, które nie dostają już poprawek bezpieczeństwa albo dostają je w ograniczonym zakresie. Aktualizacja bywa prosta, ale przy mocno przerobionym szablonie i kilkunastu płatnych modułach staje się osobnym projektem.

Przed decyzją sprawdzamy trzy rzeczy: ile modułów ma odpowiedniki w nowej wersji, jak bardzo zmieniony jest szablon i czy istnieją własne przeróbki w kodzie silnika. Ostatni punkt jest najważniejszy, bo aktualizacja nadpisuje takie zmiany i sklep po wdrożeniu przestaje działać tak jak wcześniej.

Czasem wniosek brzmi: zamiast aktualizować, zbudować sklep od nowa i przenieść dane. Bywa to porównywalne kosztowo, a zostawia sklep, który da się rozwijać przez kolejne lata. Obsługujemy wersje od 1.6 do 9.

Wersja PHP, serwer i zgodność modułów

Każda wersja PrestaShop działa z określonym zakresem wersji PHP. Sklep na starej wersji często wymaga starego PHP, a hosting z czasem przestaje je obsługiwać. Wtedy aktualizację trzeba przeprowadzić w terminie narzuconym przez dostawcę serwera.

Warto więc wiedzieć z wyprzedzeniem, do kiedy dostawca serwera utrzyma obecną wersję i które moduły nie będą działać po zmianie. Lista modułów bez odpowiedników w nowszych wersjach to najważniejsza informacja przy planowaniu aktualizacji.

Przy okazji dobrze jest sprawdzić, czy serwer odpowiada skali sklepu. O parametrach serwera pod sklep piszemy w artykule o wyborze hostingu. Zasady są podobne niezależnie od platformy.

Moduły płatne i licencje

Przy przejmowaniu sklepu po innym wykonawcy najczęstszą nieprzyjemną niespodzianką są moduły płatne kupione na jego konto. Działają dalej, ale nie da się ich zaktualizować bez jego udziału.

Uporządkowanie tego bywa możliwe przez przepisanie licencji, czasem wymaga zakupu na nowo. Warto to ustalić i poznać koszt, zanim zdarzy się awaria.

Na przyszłość zasada jest prosta: wszystkie licencje kupowane na konto firmy, na firmowy adres e-mail, do którego dostęp ma więcej niż jedna osoba.

Zmiany w szablonie i nadpisania modułów

PrestaShop pozwala zmieniać wygląd i działanie sklepu na kilka sposobów: w motywie potomnym, przez nadpisanie szablonów modułów w katalogu motywu albo przez nadpisania klas silnika. Dwa pierwsze sposoby są stosunkowo bezpieczne. Trzeci bywa najszybszy przy wdrożeniu, ale najwięcej kosztuje przy każdej aktualizacji.

Nadpisanie klasy zmienia zachowanie silnika dla całego sklepu. Gdy kolejna wersja zmieni oryginalny kod, nadpisanie nadal działa według starej logiki i potrafi po cichu psuć przeliczanie koszyka, dostaw albo cen. Gdy dwa moduły próbują nadpisać tę samą metodę, drugiego zwykle nie da się zainstalować bez ręcznego łączenia ich kodu.

Dlatego w ramach opieki warto prowadzić listę wszystkich zmian: co zmieniono, w którym pliku, po co i kto to zlecił. Przed aktualizacją ta lista mówi, co trzeba sprawdzić, a przy zmianie wykonawcy oszczędza tygodnie odkrywania sklepu od nowa.

Bezpieczeństwo panelu i modułów

Panel administracyjny sklepu daje dostęp do danych klientów i zamówień, więc wymaga ochrony lepszej niż zwykła strona. Podstawą są osobne konta dla każdej osoby, uprawnienia ograniczone do potrzebnych działań i silne hasła z logowaniem dwuskładnikowym tam, gdzie to możliwe.

Drugim źródłem ryzyka są moduły z nieznanych źródeł. Moduł pobrany za darmo z przypadkowej strony, zamiast kupiony u autora, bywa zmodyfikowany i zawiera kod, który przekazuje dane na zewnątrz.

Warto też regularnie przeglądać listę pracowników z dostępem do panelu. Konto osoby, która odeszła z firmy rok temu, nie powinno nadal działać.

• Wspólne konto administratora dla kilku osób
• Moduły pobrane spoza oficjalnych źródeł
• Pracownicy obsługi zamówień z pełnymi uprawnieniami
• Konta byłych pracowników i wykonawców

Wydajność przy rosnącym katalogu

PrestaShop zwalnia w sposób przewidywalny: wraz z liczbą produktów, kombinacji i filtrów. Sklep, który przy małym katalogu działał sprawnie, po kilkukrotnym wzroście asortymentu potrafi ładować listing kilka sekund.

Typowe przyczyny: brak indeksów w bazie po imporcie, filtry przeliczane przy każdym wejściu, wyłączone mechanizmy pamięci podręcznej i zdjęcia serwowane w rozmiarach oryginalnych.

Przy większych katalogach warto sprawdzić też, czy serwer odpowiada skali. Sklepu z kilkunastoma tysiącami pozycji na najtańszym hostingu sama optymalizacja kodu nie uratuje. Więcej o tym przy optymalizacji baz danych.

Porządki w bazie: koszyki, dzienniki i statystyki

Baza sklepu rośnie także bez nowych produktów i zamówień. Porzucone koszyki, sesje odwiedzających, dzienniki zdarzeń i statystyki odwiedzin potrafią po kilku latach zajmować więcej miejsca niż dane, które są naprawdę potrzebne.

Regularne czyszczenie tych tabel przyspiesza panel i listing, skraca czas wykonywania kopii i zmniejsza ryzyko problemów przy aktualizacji. Wymaga jednak ostrożności, bo część danych jest potrzebna do raportów sprzedaży i nie powinna zniknąć.

Gdy baza jest naprawdę duża, porządki stają się osobnym projektem. Opisujemy to w artykule o tym, dlaczego baza danych zwalnia, i przy optymalizacji baz danych.

Integracje: gdzie najczęściej się psuje

Sklep wymieniający dane z systemem magazynowym ma jeden dodatkowy punkt awarii, którego skutki widać z opóźnieniem. Rozjazd stanów narasta przez kilka dni, zanim ktoś zauważy.

Dlatego w ramach opieki warto sprawdzać, czy synchronizacja działa i czy błędy nie giną w logach. Liczba zsynchronizowanych pozycji, lista produktów, które wypadły z wymiany, i porównanie stanów kontrolnych: te trzy rzeczy warto mieć raz w tygodniu.

Integracje psują się najczęściej po aktualizacji jednej ze stron. Dlatego aktualizacje warto najpierw testować na kopii, a dopiero potem wprowadzać na produkcję.

Sprzedaż do firm na PrestaShop: grupy klientów i cenniki

Część sklepów sprzedaje klientom indywidualnym i firmom jednocześnie. Tak działają na przykład hurtownie, producenci i dystrybutorzy obsługujący warsztaty i sklepy. Taki sklep pracuje w kilku trybach naraz: z cenami netto, osobnymi cennikami i minimalną wartością zamówienia.

Dla opieki oznacza to więcej do sprawdzania. Test zakupu trzeba przejść osobno na koncie klienta indywidualnego i na koncie firmowym, bo błąd w grupie klientów widzą tylko osoby do niej przypisane. Klient hurtowy, który zobaczy ceny detaliczne, rzadko zgłasza błąd. Częściej dzwoni do handlowca albo zamawia gdzie indziej.

• Ceny i rabaty widoczne poprawnie dla każdej grupy klientów
• Ukrywanie cen lub produktów przed niezalogowanymi odwiedzającymi
• Metody płatności i dostawy przypisane do właściwych grup
• Dane firmy i numer NIP przekazywane do dokumentu sprzedaży
• Nowe konta firmowe akceptowane i przypisywane do grupy bez opóźnień

Przed większymi zmianami w takim sklepie dobrze jest zlecić przegląd całości. Szczegóły: audyty sklepów PrestaShop w Lublinie. Obsługujemy też sklepy ze wschodniej części regionu, na przykład w ramach opieki nad PrestaShop w Chełmie.

Poczta ze sklepu: potwierdzenia, które nie docierają

Klient, który nie dostał potwierdzenia zamówienia, pisze do sklepu albo składa zamówienie drugi raz. Część klientów uznaje, że zamówienie nie przeszło, i kupuje gdzie indziej.

Przyczyną jest zwykle wysyłka poczty bezpośrednio z serwera sklepu, bez poprawnych wpisów w domenie i bez zewnętrznej usługi do wysyłki. Wiadomości trafiają do spamu, a sklep nie dostaje o tym żadnej informacji.

W ramach opieki warto regularnie wysyłać testowe zamówienie na kilka popularnych skrzynek i sprawdzać, gdzie trafia potwierdzenie. To prosty test, który wykrywa problem, zanim zgłoszą go klienci.

Allegro i porównywarki: synchronizacja ofert

Wiele sklepów na PrestaShop wystawia produkty także na Allegro i w porównywarkach cen. Każdy z tych kanałów to kolejna wymiana danych, która może się rozjechać: cena w sklepie inna niż na aukcji, produkt niedostępny w magazynie, ale nadal wystawiony.

W opiece nad takim sklepem trzeba sprawdzać integrację i jej skutki: czy stany zgadzają się we wszystkich kanałach, czy zamówienia z zewnątrz trafiają do sklepu i czy pliki dla porównywarek aktualizują się bez błędów.

Szczegóły opisujemy w artykule o integracji sklepu z systemem magazynowym.

Kopie zapasowe sklepu: co dokładnie kopiować

Kopia sklepu obejmuje pliki i bazę danych. Baza zawiera produkty, zamówienia, klientów i konfigurację, a bez niej pliki są bezużyteczne. Kopia bez bazy to częsty błąd.

Częstotliwość ma tu większe znaczenie niż przy stronie firmowej. Codzienna kopia oznacza, że w najgorszym razie tracicie zamówienia z jednego dnia, a przy sklepie z realną sprzedażą to już wymierna strata.

Warto też trzymać dłuższą historię. Przy infekcji albo błędnym imporcie kopia sprzed doby często już zawiera problem; potrzebna jest wcześniejsza. Trzydzieści dni to rozsądne minimum.

• Kopia obejmująca pliki, ale nie bazę danych
• Kopie przechowywane na tym samym serwerze co sklep
• Brak środowiska testowego, zmiany robione na żywym sklepie
• Aktualizacje wprowadzane bez testu ścieżki zakupowej
• Moduły płatne przypisane do konta byłego wykonawcy

Przygotowanie do sezonu

Przed okresami wzmożonej sprzedaży warto sprawdzić trzy rzeczy: wydajność pod obciążeniem, poprawność konfiguracji dostaw i promocji oraz to, czy integracje wytrzymają zwiększoną liczbę zamówień.

Tę pracę trzeba wykonać dwa, trzy tygodnie wcześniej. W dniu kampanii na poprawki wydajności jest już za późno.

Warto też zamrozić zmiany na czas szczytu. Wdrażanie nowego modułu w tygodniu największej sprzedaży to niepotrzebne ryzyko, a zdarza się zaskakująco często.

Promocje, kody rabatowe i ceny: błędy, które kosztują

Reguły koszyka, ceny specjalne i kody rabatowe to miejsce, w którym sklep potrafi tracić pieniądze niezauważenie. Pomyłka nie wywołuje żadnego błędu: zamówienia przychodzą, klienci są zadowoleni, a marża znika na produktach, których promocja nie miała obejmować.

Problemy biorą się zwykle z nakładania się ustawień wprowadzanych przez różne osoby w różnym czasie. Kod z akcji sprzed roku nadal działa, cena specjalna dla grupy klientów łączy się z rabatem ogólnym, a promocja ustawiona bez daty końca trwa, aż ktoś ją zauważy.

• Kody rabatowe bez daty ważności i limitu użyć
• Kilka reguł koszyka łączących się ze sobą bez zamierzenia
• Ceny specjalne dla grup klientów sumujące się z promocją ogólną
• Darmowa dostawa naliczana także dla produktów wielkogabarytowych
• Rabat procentowy obejmujący produkty już objęte obniżką

Przed każdym sezonem warto przejrzeć listę aktywnych reguł i cen specjalnych, wyłączyć nieaktualne i złożyć testowe zamówienie z typowym koszykiem promocyjnym. To kilkadziesiąt minut pracy, które chronią przed sprzedażą poniżej kosztów w najbardziej ruchliwym tygodniu roku.

Widoczność sklepu po aktualizacjach

Aktualizacja albo zmiana modułu może zmienić adresy produktów i kategorii. Dla klientów sklep nadal działa, ale wyszukiwarka trafia na stare adresy, które kończą się błędem, i powoli usuwa je z wyników.

Dlatego po każdej większej zmianie warto sprawdzić, czy adresy pozostały takie same, a jeśli się zmieniły, ustawić przekierowania. Pomaga lista najważniejszych adresów zapisana przed aktualizacją i porównana po niej.

Podobnie z danymi strukturalnymi produktów: ceną, dostępnością, opiniami. Po aktualizacji szablonu potrafią zniknąć, co widać dopiero po kilku tygodniach w wyglądzie wyników wyszukiwania.

Co powinna obejmować stała opieka

Poniższa lista to zakres, który sprawdza się w typowym sklepie. Nie każdy punkt jest potrzebny wszędzie, ale pominięcie któregoś powinno mieć uzasadnienie.

• Aktualizacje silnika i modułów, najpierw na kopii testowej
• Kopia plików i bazy przechowywana poza serwerem sklepu
• Comiesięczny test zakupu: koszyk, dostawa, płatność, faktura, mail
• Monitoring dostępności i czasu odpowiedzi
• Kontrola poprawności integracji z magazynem i kurierami
• Przegląd wydajności listingu i wyszukiwarki wewnętrznej
• Porządkowanie bazy: koszyki porzucone, logi, stare sesje
• Pula godzin na zmiany w treści, kategoriach i konfiguracji

Awaria czy zmiana: jak zgłaszać i czego oczekiwać

Wiele nieporozumień w opiece nad sklepem bierze się z tego, że obie strony inaczej rozumieją słowo „pilne”. Dla właściciela pilna jest nowa promocja na jutro, dla wykonawcy płatność, która przestała działać. Warto to ustalić na piśmie, zanim pojawi się pierwsze zgłoszenie.

Dobre zgłoszenie oszczędza czas po obu stronach. Wystarczy adres podstrony, opis kroków, które prowadzą do błędu, zrzut ekranu i informacja, od kiedy problem występuje. Zgłoszenie „coś nie działa” wymaga najpierw kilku telefonów, zanim ktokolwiek zacznie szukać przyczyny.

Przy porównywaniu ofert opieki takie ustalenia mówią więcej niż sam koszt. Jeśli nie wiecie, czy sklep potrzebuje zmian technicznych, czy raczej pracy nad ofertą, zajrzyjcie do artykułu dlaczego sklep nie sprzedaje.

Raport miesięczny: co powinien zawierać

Opieka bez raportu jest dla właściciela sklepu niewidoczna aż do pierwszej awarii. Krótki raport raz w miesiącu pokazuje, co zostało zrobione i na co zwrócić uwagę.

Przejęcie sklepu po innym wykonawcy

Sporo zgłoszeń zaczyna się od zdania, że poprzednia firma przestała odpisywać. Pierwszym krokiem jest wtedy inwentaryzacja: co jest zainstalowane, w jakiej wersji, gdzie leżą kopie, jakie moduły są płatne i czy licencje są przypisane do właściwej firmy.

Drugim jest sprawdzenie, czy istnieje środowisko testowe. Jeśli nie, zakładamy je przed jakąkolwiek zmianą. Praca na żywym sklepie to częsta przyczyna awarii przy przejmowaniu projektów.

Trzecim jest lista znalezisk uporządkowana według pilności i kosztu. Nawet jeśli nie zdecydujecie się na dalszą współpracę, wiecie, co macie.

Sklepy z Lubelszczyzny: opieka na miejscu i na odległość

Większość prac przy sklepie wykonuje się na odległość: aktualizacje, testy, kopie i monitoring nie wymagają obecności w firmie. Spotkanie ma sens na starcie współpracy i przy większych zmianach, gdy trzeba zrozumieć, jak wygląda obsługa zamówień i magazyn.

Dla sklepów z Lublina, Zamościa czy Puław taki model łączy szybką reakcję na zgłoszenia z możliwością spotkania, gdy trzeba omówić plan albo przeszkolić osoby obsługujące sklep.

Więcej o zakresie przy opiece nad PrestaShop w Lublinie i w Zamościu.

Jak wybrać firmę do opieki nad sklepem

Oferty opieki często wyglądają podobnie: aktualizacje, kopie, pula godzin. Różnice wychodzą w szczegółach, które warto ustalić przed podpisaniem umowy.

• Testowanie aktualizacji najpierw na kopii sklepu
• Test zakupu z realną płatnością i dokumentem sprzedaży
• Miejsce przechowywania kopii i data ostatniego testu odtworzenia
• Czas reakcji na awarię i godziny, w których obowiązuje
• Raport z wykonanych prac
• Właściciel licencji modułów kupowanych w trakcie współpracy

Kiedy opieka nie wystarcza

Opieka utrzymuje sklep w dobrym stanie, ale nie zmieni jego fundamentów. Jeśli każda aktualizacja wymaga tygodni pracy, szablon blokuje zmiany, a sprzedaż rośnie szybciej, niż sklep jest w stanie ją obsłużyć, warto zastanowić się nad przebudową.

Sygnałami są: coraz wyższy koszt utrzymania przy tym samym zakresie, moduły bez wsparcia autorów, brak możliwości wdrożenia potrzebnych funkcji i powtarzające się problemy z wydajnością mimo optymalizacji.

Decyzję o przebudowie warto podjąć spokojnie, poza sezonem, na podstawie przeglądu technicznego i sprzedażowego. Pomagamy w tym przy budowie sklepów internetowych.