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; w sklepie — płatność, która przechodzi, choć zamówienie nie zapisuje się w systemie.

Dlatego opieka nad sklepem to nie tylko aktualizacje. To także 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.

Najgroźniejsze awarie są niewidoczne

Awarię, przy której sklep nie działa, widać natychmiast — telefon dzwoni w ciągu godziny. 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. Wszystkie objawiają się tak samo — ciszą.

Dlatego comiesięczny test zakupu realną transakcją na niską kwotę jest najważniejszą pojedynczą czynnością w całej opiece. Kwotę się zwraca, a Wy macie pewność, że proces działa dziś, a nie działał w dniu wdrożenia.

Test zakupu krok po kroku

Comiesięczny test zakupu ma sens tylko wtedy, gdy obejmuje całą ścieżkę, a nie samo dodanie produktu do koszyka. 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ć

Duża część sklepów w Polsce 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 kluczowy — takie zmiany znikają przy aktualizacji i wracają jako niespodzianka po wdrożeniu.

Czasem wniosek brzmi: nie aktualizować, tylko zbudować sklep od nowa i przenieść dane. Wychodzi to podobnie kosztowo, a zostawia sklep, który da się rozwijać przez kolejne lata.

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 aktualizacja przestaje być wyborem i staje się koniecznością z terminem.

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. Ważne, żeby wiedzieć o tym wcześnie i mieć jasną informację o koszcie przed decyzją, a nie w trakcie awarii.

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. To trywialne, dopóki się o tym pamięta.

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 i najdroższy 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 nadpisują to samo miejsce, jeden z nich przestaje działać tak, jak powinien.

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 pięciuset produktach działał świetnie, przy pięciu tysiącach potrafi ładować listing kilka sekund.

Typowe przyczyny są znane: 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. Sklep z kilkunastoma tysiącami pozycji na najtańszym hostingu to problem, którego nie rozwiąże żadna optymalizacja kodu — szerzej przy optymalizacji baz.

Porządki w bazie: koszyki, dzienniki i statystyki

Baza sklepu rośnie nie tylko przez produkty i zamówienia. 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 — 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, i to taki, którego skutki widać z opóźnieniem. Rozjazd stanów narasta przez kilka dni, zanim ktoś zauważy.

Dlatego w ramach opieki warto sprawdzać nie tylko, czy synchronizacja działa, ale też 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 — to trzy rzeczy, które warto mieć raz w tygodniu.

Integracje psują się najczęściej nie same z siebie, tylko po aktualizacji jednej ze stron. To argument za tym, żeby aktualizacje testować na kopii, a nie wprowadzać od razu na produkcję.

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

Część sklepów z regionu sprzedaje nie tylko klientom indywidualnym, ale też firmom: hurtownie z Lublina i Lubartowa, producenci z okolic Kraśnika, dystrybutorzy obsługujący warsztaty i sklepy w całym województwie. Taki sklep działa 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, zwykle nie zgłasza błędu, tylko 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 — zobacz 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ć nie tylko samą integrację, ale też 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 to nie tylko pliki. Baza danych zawiera produkty, zamówienia, klientów i konfigurację — bez niej pliki są bezużyteczne. Kopia bez bazy jest częstym i kosztownym błędem.

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 kwota.

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ń.

To praca, którą trzeba wykonać z wyprzedzeniem — dwóch, trzech tygodni. Testowanie wydajności w dniu kampanii jest gaszeniem pożaru, a nie przygotowaniem.

Warto też zamrozić zmiany na czas szczytu. Wdrażanie nowego modułu w tygodniu największej sprzedaży to ryzyko, którego nikt nie potrzebuje, a które podejmuje 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 traci pieniądze najciszej. Pomyłka nie wywołuje żadnego błędu: zamówienia przychodzą, klienci są zadowoleni, a marża znika na produktach, których promocja w ogóle 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, 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 nie — 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ę przy większości sklepów. Nie każdy punkt jest potrzebny w każdym przypadku, ale brak któregoś zawsze da się uzasadnić — a nie pominąć milczeniem.

• 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ż sama cena. 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, z której nie ma raportu, jest dla właściciela sklepu niewidoczna — 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 — sprawdzenie, czy istnieje środowisko testowe. Jeśli nie, zakładamy je przed jakąkolwiek zmianą. Praca na żywym sklepie jest najczęstszą przyczyną 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 — a to zwykle najbardziej wartościowa część pierwszego miesiąca.

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 obie zalety: szybką reakcję na zgłoszenia i możliwość 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ą dopiero w szczegółach, które warto sprawdzić przed podpisaniem umowy.

• Czy aktualizacje są najpierw testowane na kopii sklepu?
• Czy test zakupu obejmuje realną płatność i dokument sprzedaży?
• Gdzie przechowywane są kopie i kiedy ostatnio je odtwarzano?
• Jaki jest czas reakcji na awarię i w jakich godzinach?
• Czy dostajecie raport z wykonanych prac?
• Na kogo zarejestrowane są licencje 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.