Co zmienia wersja 9

Przejście z ósemki na dziewiątkę dotyczy także technologii, na których działa sklep. PrestaShop 9.0 przeszedł z Symfony 4.4 na Symfony 6.4. To zmiana istotna przede wszystkim dla autorów modułów i osób utrzymujących własne modyfikacje. Kod korzystający ze starszych mechanizmów może wymagać dostosowania, nawet jeśli od strony klienta funkcja ma wyglądać identycznie. Zakres zmian opisuje dokumentacja zmian w PrestaShop 9.0.

Wymagania serwera sprawdzaj dla konkretnego wydania, które zamierzasz wdrożyć. Informacja „hosting obsługuje PrestaShop” jest zbyt ogólna. Potrzebna jest zgodna wersja PHP, odpowiednie rozszerzenia, baza danych i zasoby pozwalające wykonywać importy oraz zadania w tle. Punktem odniesienia jest oficjalna tabela wymagań. Osobno sprawdź PHP obsługujące stronę i PHP uruchamiane przez harmonogram zadań.

Dla właściciela sklepu znaczenie ma wynik: możliwość dalszego utrzymania systemu, dostępność potrzebnych rozszerzeń i działanie procesów sprzedażowych. Nie zakładaj, że aktualizacja sama przyspieszy katalog, naprawi wyszukiwarkę lub uprości pracę magazynu. Takie efekty wymagają osobnej diagnozy i pomiarów przed zmianą oraz po niej.

Największą niewiadomą bywają moduły i motyw

W standardowej instalacji zakres prac można oszacować stosunkowo łatwo. W sklepie rozwijanym przez kilka lat lista modułów nie mówi jeszcze, co naprawdę trzeba przenieść. Moduł płatności mógł dostać lokalną poprawkę, motyw korzystać ze zmienionego koszyka, a integracja z ERP odwoływać się bezpośrednio do bazy. Każdy taki element trzeba rozpoznać przed wyceną.

Deklaracja producenta o zgodności jest dobrym początkiem, ale dotyczy określonej wersji jego produktu. Sprawdź, czy posiadana licencja obejmuje dostęp do tego wydania i czy aktualizacja zachowa konfigurację. Jeżeli ktoś zmieniał pliki modułu, pobranie nowej paczki może usunąć te modyfikacje. Własny kod trzeba porównać z oryginałem i zdecydować, które różnice nadal są potrzebne.

Motyw również wymaga próby. Strona główna może wyglądać poprawnie, podczas gdy wybór kombinacji produktu, walidacja adresu albo płatność na telefonie przestają działać. Przy motywie dedykowanym potrzebne są źródła i instrukcja budowania plików. Przy gotowym motywie liczy się dostępność aktualizacji oraz zgodność dodatków dostarczonych razem z nim.

Jak sprawdzić, na czym stoisz

Przed rozmową o terminie przygotuj inwentaryzację. Dla każdego rozszerzenia zapisz nazwę, wersję, producenta, funkcję biznesową i osobę odpowiedzialną za utrzymanie. Dopisz informację o licencji oraz ewentualnych zmianach. Moduł, którego nikt nie potrafi opisać, wymaga sprawdzenia: może być zbędny, ale może też raz dziennie przekazywać zamówienia do magazynu.

• Ustal dokładną wersję sklepu, PHP, bazy danych i motywu.
• Zbierz listę aktywnych modułów, zadań cyklicznych i połączeń z zewnętrznymi systemami.
• Sprawdź override’y oraz bezpośrednie zmiany w plikach rdzenia.
• Zweryfikuj dostęp do kodu, kopii zapasowych i kont producentów rozszerzeń.
• Opisz nietypowe zasady cen, dostaw, rabatów i obsługi zamówień.

Wynikiem powinien być dokument dzielący elementy na gotowe do przeniesienia, wymagające poprawki, zastąpienia lub usunięcia. Przy każdej niewiadomej potrzebny jest sposób jej wyjaśnienia. Jeśli sklep ma wiele nadpisań, pomocny będzie osobny przegląd override’ów w PrestaShop. Bez tej pracy „aktualizacja” może skrywać przebudowę kilku ważnych funkcji.

Kiedy warto przesunąć termin

Wdrożenie tuż przed najważniejszą kampanią sprzedażową zwiększa koszt ewentualnej pomyłki. Jeśli nie ma pilnej przyczyny bezpieczeństwa, rozsądniej przygotować i przetestować zmianę wcześniej, a przełączenie zaplanować poza szczytem. Przesunięcie terminu powinno jednak mieć konkretną datę i warunki, które trzeba do niej spełnić.

Drugim powodem jest brak zgodności funkcji niezbędnej do sprzedaży. Jeżeli nie działa operator płatności albo integracja przekazująca zamówienia do ERP, sam fakt uruchomienia sklepu na nowym rdzeniu niewiele daje. Najpierw potrzebna jest poprawka, zamiennik lub uzgodniona procedura tymczasowa. Nie zakładaj, że producent zdąży, dopóki nie masz wersji, którą można sprawdzić.

Warto też połączyć prace, jeśli firma już przygotowuje wymianę motywu albo migrację na inną platformę. Dostosowywanie części przeznaczonej za chwilę do usunięcia bywa zbędnym kosztem. Warunkiem takiej decyzji jest możliwość bezpiecznego utrzymania obecnego sklepu do czasu następnego wdrożenia.

Kiedy zwlekanie utrudnia utrzymanie sklepu

Odłożenie aktualizacji nie zatrzymuje zmian u pozostałych dostawców. Hosting aktualizuje środowisko, operator płatności zmienia integrację, a producent modułu rozwija kolejne wydania. Jeśli sklep wymaga coraz większej liczby wyjątków, każdą nową funkcję trzeba najpierw dopasować do starych ograniczeń. Ten nakład powinien pojawić się w porównaniu kosztów.

Sprawdź aktualny status wsparcia używanego wydania i jego zależności. Dostępność poprawek bezpieczeństwa nie wynika z tego, że sklep nadal przyjmuje zamówienia. Gdy pojawia się problem bezpieczeństwa, decyzję o terminie trzeba oprzeć na jego znaczeniu dla danej instalacji i dostępnych zabezpieczeniach, a nie wyłącznie na kalendarzu kampanii.

Porównaj dwa warianty na tym samym okresie: uporządkowanie i aktualizację teraz oraz dalsze utrzymanie wraz z późniejszym przejściem. W drugim wariancie uwzględnij poprawki zgodności, dodatkowe testy i prace, które później trzeba będzie wykonać ponownie. Takie zestawienie daje lepszą podstawę decyzji niż przekonanie, że działającego sklepu nigdy nie należy ruszać.

Jak przygotować bezpieczną aktualizację

Zacznij od kopii plików i bazy oraz próby odtworzenia. Następnie uruchom osobne środowisko testowe. Zablokuj na nim dostęp osób postronnych i indeksowanie, wyłącz wysyłkę do klientów, a płatności oraz integracje przełącz w odpowiedni tryb testowy. Kopia produkcji nie może przypadkiem tworzyć prawdziwych przesyłek ani przekazywać powielonych zamówień.

Na kopii przeprowadź pełną aktualizację i zapisz wszystkie dodatkowe kroki. Testuj procesy: zakup gościnny i po zalogowaniu, kombinacje produktów, rabaty, dostawy, płatności, potwierdzenia operatora, wiadomości oraz eksport do ERP. Sprawdź także anulowanie zamówienia i zwrot. Poproś pracownika obsługi o wykonanie jego zwykłych zadań, bo nie wszystkie wyjątki widać w dokumentacji.

Przed przełączeniem określ moment wstrzymania zapisów, wykonania świeżej kopii i uruchomienia nowej wersji. Ustal, kto podejmuje decyzję o wycofaniu oraz jak zostaną rozliczone płatności przychodzące w tym czasie. Powrót do starej bazy po przyjęciu nowych zamówień wymaga ich zabezpieczenia i uzgodnienia danych. Samo przywrócenie plików nie rozwiązuje tego problemu.

Przed zatwierdzeniem wdrożenia warto też ustalić sposób odbioru. Przygotuj tabelę z nazwą testu, oczekiwanym wynikiem, osobą sprawdzającą i statusem. Jeśli jakiś przypadek nie przeszedł, opisz jego wpływ na sprzedaż. Drobna różnica wizualna i niepoprawne naliczanie ceny nie powinny mieć tej samej wagi. Decyzję o uruchomieniu podejmuj na podstawie tej listy, a nie samego komunikatu, że narzędzie zakończyło aktualizację bez błędu. Zachowaj wyniki próby przy dokumentacji projektu, żeby następny wykonawca wiedział, co rzeczywiście zweryfikowano i które ograniczenia zaakceptowała firma.

Najczęstsze pytania

Czy da się zaktualizować sklep bez przestoju?

Większość przygotowań można wykonać podczas normalnej sprzedaży. Samo przełączenie może wymagać krótkiego wstrzymania zamówień, żeby zachować spójność danych. Obietnica zerowej przerwy wymaga konkretnego rozwiązania technicznego i próby całej procedury.

Co z modułami, których producent już nie rozwija?

Najpierw sprawdź, czy ich funkcja nadal jest potrzebna. Jeśli tak, trzeba znaleźć zamiennik albo zlecić dostosowanie kodu z uwzględnieniem licencji. W obu przypadkach ustal, kto będzie później odpowiadał za poprawki.

Czy aktualizacja wpłynie na pozycje w Google?

Sam numer wersji nie daje gwarancji poprawy ani spadku widoczności. Sprawdź adresy, treści, linki kanoniczne, indeksowanie i odpowiedzi serwera przed wdrożeniem oraz po nim. Jeśli zmieniasz także strukturę URL, potrzebny jest osobny plan przekierowań.

Ile trwa aktualizacja wersji głównej?

Czas zależy przede wszystkim od zgodności rozszerzeń, zakresu własnego kodu i liczby procesów do przetestowania. Wiarygodny termin powstaje po inwentaryzacji oraz próbie na kopii. Sam czas uruchomienia narzędzia aktualizującego jest tylko częścią pracy.

Od czego zacząć decyzję

Poproś wykonawcę o listę przeszkód, plan testów i procedurę przełączenia. Dopiero na tej podstawie zatwierdzaj budżet i termin. Jeśli potrzebujesz pomocy w ustaleniu zakresu, sprawdź migracje i aktualizacje sklepów.

Artykuł PrestaShop 8 czy 9: kiedy aktualizować, a kiedy poczekać pochodzi z serwisu eCommerce Expert.

Zanim cokolwiek zmienisz

Ustal zakres awarii. Czy nie otwiera się żadna strona, tylko panel administracyjny, czy konkretny krok zamówienia? Sprawdź jeden przykład bez logowania i drugi na koncie testowym. Zanotuj użyty produkt, metodę dostawy oraz czynność poprzedzającą błąd. Jeśli problem dotyczy płatności, nie powtarzaj zakupów na ślepo: najpierw sprawdź, czy operator nie pobrał już pieniędzy.

Zapisz ostatnie zmiany. Aktualizacja modułu, przełączenie PHP, wdrożenie motywu, import produktów i zmiana ustawień hostingu tworzą różne tropy. Godzina zgłoszenia nie musi być godziną początku awarii. Porównaj ją z ostatnimi poprawnymi zamówieniami i logami, żeby nie przypisać problemu zmianie wykonanej już po jego wystąpieniu.

Przed ingerencją wykonaj kopię bazy i plików albo poproś hosting o zabezpieczenie bieżącego stanu. Nie nadpisuj ostatniej sprawnej kopii. Baza z czasu awarii może zawierać zamówienia i płatności, których nie ma we wczorajszym backupie. Jeśli brakuje miejsca na dysku, tworzenie dużego archiwum na tym samym serwerze może pogorszyć sytuację. Wtedy uzgodnij z administratorem inny sposób wykonania kopii.

Gdzie szukać logów

Potrzebne mogą być dzienniki serwera WWW, PHP i samej aplikacji. Na hostingu współdzielonym zacznij od sekcji logów w panelu. Jeśli nie masz do nich dostępu, przekaż obsłudze dokładny adres, godzinę wraz ze strefą czasową i opis czynności. Prośba „sklep nie działa” zostawia znacznie więcej miejsca na zgadywanie.

Na VPS lokalizacja zależy od konfiguracji Apache lub nginx, PHP-FPM i sposobu uruchomienia sklepu. W środowisku kontenerowym część logów może trafiać do wyjścia procesu zamiast do osobnego pliku. W instalacji PrestaShop sprawdź także katalog logów aplikacji, zwykle w obrębie var/logs, uwzględniając używaną wersję i konfigurację. Brak wpisu w jednym miejscu nie oznacza braku błędu.

Szukaj zdarzenia odpowiadającego czasowi próby. Odczytaj pierwszy istotny wyjątek oraz jego otoczenie, nie tylko ostatnią linię. Komunikat o braku klasy może być skutkiem niepełnego wdrożenia, a błąd połączenia z bazą skutkiem jej niedostępności. Zachowaj oryginalny fragment do analizy. Przed przekazaniem go poza uprawniony zespół usuń hasła, tokeny i dane klientów.

Tryb debugowania: jak go użyć

Jeżeli panel działa, tryb debugowania można włączyć w ustawieniach wydajności w parametrach zaawansowanych. Przy braku dostępu do panelu dokumentacja PrestaShop opisuje zmianę stałej _PS_MODE_DEV_ w pliku config/defines.inc.php. Zmień istniejącą definicję, zamiast dopisywać drugą. Sposób konfiguracji przedstawia oficjalna instrukcja debugowania.

Rób to na zabezpieczonej kopii albo w środowisku z ograniczonym dostępem. Szczegółowy komunikat może ujawnić ścieżki, zapytania i informacje o konfiguracji. Włączony debug nie jest sposobem naprawy: pomaga zobaczyć przyczynę. Po zapisaniu potrzebnych danych wyłącz go i sprawdź zachowanie sklepu w zwykłym trybie.

Jeżeli błąd powstaje przed uruchomieniem PHP lub aplikacji, tryb debugowania PrestaShop niczego nie pokaże. W takim przypadku trzeba wrócić do logów serwera i konfiguracji hostingu. Nie zwiększaj liczby zmian tylko dlatego, że na ekranie nadal widzisz ten sam ogólny komunikat.

Jak odróżnić typowe przyczyny

Brak pamięci PHP

Komunikat zawierający Allowed memory size exhausted wskazuje na przekroczenie limitu pamięci procesu. Ustal, jaka czynność do tego doprowadziła. Import dużego pliku i nieskończona pętla w module wymagają innych rozwiązań. Zwiększenie limitu może być uzasadnione, ale dopiero po sprawdzeniu zużycia oraz dostępnych zasobów serwera.

Niezgodność wersji PHP lub rozszerzenia

Jeśli awaria zaczęła się po zmianie środowiska, porównaj wersję PHP z wymaganiami dokładnego wydania sklepu i modułów. Błąd składni, brak funkcji albo niezgodna deklaracja metody to wskazówki do dalszej analizy. Przywrócenie poprzedniej konfiguracji może pomóc odizolować zmianę, ale docelowo potrzebna jest wspierana i zgodna kombinacja oprogramowania.

Moduł, override lub niepełne wdrożenie

Ścieżka do rozszerzenia w stosie wywołań wskazuje miejsce wystąpienia błędu, ale nie zawsze jego źródło. Sprawdź kompletność plików, zależności i ostatnią zmianę. Gdy komunikat dotyczy nadpisanej metody, przyjrzyj się override’om. Samo skopiowanie brakującego pliku z przypadkowej wersji może wprowadzić kolejną niezgodność.

Cache i uprawnienia

Błąd zapisu lub tworzenia pliku może wynikać z nieprawidłowego właściciela katalogu po wdrożeniu. Sprawdź użytkownika procesu PHP i wymagane uprawnienia. Nie ustawiaj masowo 777 na całym sklepie. Jeśli przyczyną są nieaktualne pliki cache, odtwórz je zgodnie z procedurą dla danej wersji, po zachowaniu logów potrzebnych do diagnozy.

Brak miejsca albo niedostępna baza

Sprawdź miejsce na dysku i limit liczby plików. Pełny dysk może uniemożliwić zapis sesji, cache i logów, więc brak nowego komunikatu również bywa objawem. Przy błędach połączenia z bazą zweryfikuj jej dostępność i limity połączeń. Nie uruchamiaj napraw tabel ani nie zmieniaj danych logowania bez potwierdzenia przyczyny.

Gdy błąd pojawił się po aktualizacji

Zatrzymaj kolejne wdrożenia i porównaj stan przed zmianą z aktualnym. Sprawdź wersję pakietu, kompletność plików i informację, czy aktualizacja zmieniła bazę. Cofnięcie wyłącznie kodu może być niewystarczające, jeśli nowa wersja przekształciła dane. Plan wycofania musi uwzględniać oba elementy.

Jeśli logi wskazują jeden moduł, wyłącz go w kontrolowany sposób i powtórz dokładnie tę samą próbę. W wersjach udostępniających odpowiednie polecenie można skorzystać z konsoli PrestaShop; składnię sprawdź w pomocy zainstalowanego wydania. Jeśli aplikacja nie potrafi się uruchomić, konsola też może nie działać. Wtedy potrzebna jest analiza plików, zależności i rejestracji modułu.

Przemianowanie katalogu modułu nie jest uniwersalnym odpowiednikiem jego wyłączenia. Może pozostawić odwołania do klas i konfiguracji. Nie usuwaj też tabel modułu: mogą przechowywać dane potrzebne do rozliczenia zamówień. Po poprawce sprawdź nie tylko stronę, która wcześniej zwracała błąd, ale również zakup, potwierdzenie płatności i przekazanie zamówienia do obsługi.

Kiedy przerwać samodzielne próby

Przekaż diagnozę osobie technicznej, gdy problem dotyczy danych zamówień, podejrzenia włamania, uszkodzenia bazy lub aktualizacji, której nie potrafisz bezpiecznie wycofać. Podobnie postąp, jeśli nie masz sprawnej kopii, a każda kolejna czynność zmienia stan produkcji. Kolejne losowe poprawki utrudniają późniejsze ustalenie przyczyny.

Przygotuj krótkie zgłoszenie: wersja sklepu i PHP, zakres awarii, czas wystąpienia, ostatnie zmiany, przykładowy adres i fragment logu. Dopisz, co już zostało zrobione, także jeśli próba nie pomogła. Dostępy przekaż bezpiecznym kanałem, przez oddzielne konto z zakresem potrzebnym do pracy.

Po usunięciu przyczyny zapisz krótką notatkę: co przestało działać, jaki komunikat potwierdził diagnozę, co zmieniono i jak sprawdzono naprawę. Dołącz informację, czy trzeba obsłużyć zamówienia z czasu awarii. Taki zapis pomoże przy kolejnym zgłoszeniu i pozwoli ustalić, czy problem wraca. Jeśli awaria ujawniła brak monitoringu konkretnej płatności lub integracji, dodaj odpowiednią kontrolę do procedury utrzymania.

Najczęstsze pytania

Czy błąd 500 oznacza utratę danych?

Nie. To informacja o nieudanej obsłudze żądania, a nie o stanie wszystkich danych. Operacja mogła jednak wykonać się częściowo, dlatego przed ponowieniem płatności lub importu trzeba sprawdzić wynik po obu stronach integracji.

Jak wyłączyć moduł bez dostępu do panelu?

Jeśli dana wersja udostępnia działającą komendę konsolową, skorzystaj z niej po sprawdzeniu pomocy. Gdy uruchomienie aplikacji kończy się błędem, sposób postępowania zależy od przyczyny. Nie stosuj przypadkowego zapytania SQL znalezionego dla innego wydania.

Dlaczego sklep działa, a panel administracyjny nie?

Panel i część dostępna klientom uruchamiają różne fragmenty kodu. Awaria może dotyczyć modułu administracyjnego, konkretnego widoku lub uprawnień. Sprawdź osobno logi próby wejścia do panelu.

Czy mogę sam przywrócić kopię zapasową?

Tak, jeśli znasz procedurę i zakres danych, które zostaną zastąpione. Najpierw zabezpiecz bieżący stan oraz zamówienia powstałe po dacie kopii. Pliki, baza i ewentualne zmiany środowiska muszą do siebie pasować.

Najbardziej użyteczny pierwszy krok to znalezienie konkretnego błędu w logu i powiązanie go z czynnością w sklepie. Jeśli potrzebujesz wsparcia przy diagnozie, skorzystaj z pomocy w rozwiązywaniu problemów i dołącz przygotowane informacje.

Artykuł Błąd 500 w PrestaShop: jak znaleźć przyczynę pochodzi z serwisu eCommerce Expert.

Czym właściwie jest override

W tym artykule chodzi o nadpisywanie klas i kontrolerów, a nie o zmianę wyglądu szablonu. Taki mechanizm pozwala zastąpić lub rozszerzyć fragment standardowej logiki PrestaShop. Z perspektywy właściciela sklepu oznacza to, że część operacji może działać inaczej niż w czystej instalacji: na przykład obliczanie ceny albo warunek dostępności dostawy.

Hook jest punktem rozszerzenia, do którego moduł podłącza własne działanie. Override sięga w istniejące zachowanie bardziej bezpośrednio. Sam moduł jest natomiast sposobem dostarczenia funkcji i może korzystać z różnych mechanizmów, także z override’u. Zdanie „wszystko zrobiliśmy w module” nie daje więc odpowiedzi na pytanie o zakres ingerencji.

Dokumentacja PrestaShop wskazuje ograniczenia i ryzyko konfliktów między nadpisaniami oraz opisuje alternatywne sposoby rozszerzania systemu. Wybór zależy od miejsca w kodzie i dostępnych mechanizmów danej wersji. Punktem odniesienia jest oficjalny opis override’ów. Praktyczny wniosek: przed nadpisaniem trzeba sprawdzić, czy ten sam cel można osiągnąć przez przewidziany punkt rozszerzenia.

Dlaczego aktualizacja może ujawnić problem

Wyobraź sobie modyfikację, która przejmuje obliczanie opłaty za dostawę. Powstała dla określonej wersji sklepu i korzysta z jej argumentów oraz sposobu przetwarzania danych. Po aktualizacji rdzeń może przekazywać inne dane, wymagać innego typu wyniku albo wcześniej wykonywać dodatkową kontrolę. Własny kod nadal zakłada dawny przebieg.

Nie zawsze oznacza to białą stronę. Sklep może przyjmować zamówienia, lecz inaczej liczyć rabat dla wybranej grupy albo pomijać warunek dotyczący konkretnej dostawy. Błąd ujawnia się dopiero przy określonym koszyku. Dlatego test polegający na otwarciu strony głównej nie wystarczy do potwierdzenia zgodności.

Szczególnej uwagi wymaga skopiowanie całej metody rdzenia i dopisanie do niej małej zmiany. Takie rozwiązanie może przechowywać również dawną logikę, którą projekt później poprawił. Przy aktualizacji trzeba porównać nie tylko to, co dopisano, ale również to, co zmieniło się w oryginale. Im większa kopia, tym więcej zachowań trzeba ponownie ocenić.

Kiedy override może być uzasadniony

Czasem potrzebna funkcja dotyczy miejsca, dla którego dana wersja nie udostępnia odpowiedniego punktu rozszerzenia. Ograniczone nadpisanie może wtedy być rozsądnym wyborem, jeśli alternatywa wymaga znacznie większej przebudowy. Tę decyzję trzeba jednak opisać i uwzględnić w późniejszym utrzymaniu. Koszt nie kończy się w dniu uruchomienia.

W dokumentacji powinny znaleźć się powód zmiany, obsługiwane wersje, właściciel kodu i przykłady oczekiwanego zachowania. Potrzebna jest też informacja o rozważonych alternatywach. „Klient potrzebował innej ceny” to za mało. „Dla kontrahenta z umową A, przy zamówieniu pełnego opakowania, obowiązuje cena z ERP” pozwala przygotować test.

Ustal warunek usunięcia nadpisania. Może nim być pojawienie się odpowiedniego hooka, wymiana modułu albo rezygnacja z funkcji. Bez takiego przeglądu kod tymczasowy zostaje na lata. Każda następna osoba traktuje go jako niezbędny, bo nikt nie ma pewności, co stanie się po jego wyłączeniu.

Jak sprawdzić, co jest w Twoim sklepie

Przegląd obejmuje katalog override, kod modułów i porównanie plików rdzenia z oryginalnym wydaniem. Bezpośrednia edycja pliku rdzenia to osobny rodzaj modyfikacji; nie musi pojawić się na liście override’ów. Dlatego pusty katalog nadpisań nie jest dowodem, że sklep pozostaje standardowy.

Poproś programistę o zestawienie zrozumiałe także dla osoby odpowiedzialnej za sprzedaż. Przy każdej zmianie powinno być widać funkcję biznesową, miejsce w kodzie, źródło i sposób weryfikacji. Nazwa klasy sama w sobie nie pomoże ustalić, czy można zrezygnować z modyfikacji przy następnej aktualizacji.

• Jaką czynność klienta lub obsługi zmienia ten fragment?
• Czy pochodzi z modułu, czy został napisany na potrzeby sklepu?
• Czy jest używany i na jakich danych można to potwierdzić?
• Czy inny dodatek ingeruje w ten sam obszar?
• Jakie testy pokażą, że funkcja działa po aktualizacji?

Porównanie wykonuj z dokładnie tym wydaniem, które jest zainstalowane, a nie z dowolną paczką PrestaShop. Pliki generowane, konfiguracja i dane sklepu wymagają osobnego potraktowania. Przy przejęciu projektu pomocne są historia repozytorium i starsze paczki wdrożeniowe. Jeśli ich brakuje, trzeba jasno zaznaczyć, których ustaleń nie udało się potwierdzić.

Jak uporządkować istniejące modyfikacje

Pierwszym krokiem jest ustalenie obecnego zachowania. Zapisz przykładowe koszyki, ceny i warunki dostawy przed zmianą kodu. Dla reguł wpływających na rozliczenia przygotuj oczekiwane wyniki uzgodnione z osobą odpowiedzialną za handel. Test automatyczny bez poprawnej odpowiedzi biznesowej może tylko utrwalić dotychczasowy błąd.

Następnie sprawdź, które funkcje nadal są potrzebne. Część mogła zastąpić nowa wersja platformy lub modułu. Inne mogą dotyczyć nieużywanej metody dostawy czy zakończonej promocji. Usunięcie zbędnej modyfikacji bywa prostsze niż jej przepisywanie, ale również wymaga próby na kopii i sprawdzenia zależności.

Dla pozostałych zmian wybierz sposób realizacji: dostępny hook, usługę, dekorację tam, gdzie architektura na to pozwala, albo nadal utrzymywany override. Przeniesienie kodu do innego pliku nie wystarczy, jeśli zachowuje te same założenia o wnętrzu rdzenia. Celem jest ograniczenie zależności i ułatwienie testowania.

Pracuj etapami. Najpierw odtwórz zachowanie jednej funkcji, porównaj wyniki i dopiero potem przejdź dalej. Jednoczesna wymiana cenników, koszyka oraz integracji utrudnia ustalenie źródła różnic. Jeśli aktualizacja sklepu jest pilna, oddziel niezbędne dostosowanie od większych porządków, które mogą poczekać na osobny termin.

Jak sprawdzić zmianę przed wdrożeniem

Testuj warunki graniczne, a nie tylko najprostszy zakup. Jeśli modyfikacja dotyczy rabatu, uwzględnij produkt przeceniony, kilka sztuk, różne grupy klientów i zmianę ilości w koszyku. Przy dostawie sprawdź próg darmowej wysyłki, produkty z odmiennymi ograniczeniami i zmianę adresu. Lista powinna wynikać z reguły, którą faktycznie zmieniono.

Porównaj również zapisane dane: sumę zamówienia, wartości przekazane operatorowi płatności i dokument wysłany do ERP. Poprawna kwota widoczna na stronie nie daje pewności, że każdy system otrzymał to samo. Zapisz wyniki wraz z wersją kodu, aby później można było powtórzyć próbę.

Po wdrożeniu obserwuj obszar objęty zmianą. Uzgodnij, jakie rozbieżności wymagają natychmiastowej reakcji i kto je sprawdza. Gdy wystąpi błąd 500, zachowaj log i dane testu. Przy cichym błędzie cenowym ważniejsze będą porównania wartości niż sam monitoring dostępności strony.

Jak nie wrócić do tego za rok

W zasadach współpracy zapisz obowiązek opisania ingerencji w rdzeń i nadpisań przy każdym odbiorze. Zmiana powinna mieć źródła, uzasadnienie i test. Dostęp do repozytorium pozwala sprawdzić, co rzeczywiście wdrożono, ale sam w sobie nie zastępuje przeglądu kodu.

Przy kolejnej aktualizacji wróć do rejestru modyfikacji. Sprawdź, czy nowe wydanie nie daje prostszego rozwiązania i czy dana funkcja nadal ma właściciela po stronie biznesu. Utrzymywanie krótkiej, aktualnej listy zależności jest tańsze niż odtwarzanie ich w czasie awarii.

Ten rejestr przekazuj razem z kodem przy każdej zmianie wykonawcy i przy planowaniu aktualizacji sklepu.

Najczęstsze pytania

Czy override zawsze jest błędem?

Nie. Może rozwiązywać potrzebę, dla której brakuje odpowiedniego mechanizmu rozszerzenia. Musi jednak być świadomą decyzją z dokumentacją i planem utrzymania.

Jak poznać, że sklep ma zmiany w rdzeniu?

Porównaj jego kod z oryginalną paczką tego samego wydania i historią wdrożeń. Sam panel administracyjny nie pokaże pełnego obrazu. Ocenę różnic najlepiej zlecić osobie znającej strukturę projektu.

Ile kosztuje uporządkowanie override’ów?

Liczba plików nie jest dobrą podstawą wyceny. Jedna zmiana cennika może wymagać więcej pracy niż kilka prostych nadpisań. Potrzebny jest opis funkcji, zależności i przypadków testowych.

Czy to wpływa na bezpieczeństwo sklepu?

Może wpływać, jeśli własna logika omija kontrolę uprawnień, walidację lub zachowuje fragment wymagający poprawki. Sam fakt istnienia override’u nie dowodzi podatności. Ocenie podlega konkretna implementacja.

Przed planowaną aktualizacją PrestaShop zbierz listę zmian i ich zastosowań. Jeśli nie wiadomo, co nadpisano, zacznij od audytu technicznego, który przełoży kod na zakres prac i ryzyko dla sprzedaży.

Artykuł Override w PrestaShop: dlaczego psuje aktualizacje pochodzi z serwisu eCommerce Expert.

Czy migracja jest rzeczywiście potrzebna

Powolny sklep nie musi wymagać nowej platformy. Przyczyną mogą być nieefektywne zapytania, niewłaściwy hosting albo konkretna wtyczka. Nieaktualne stany magazynowe mogą wynikać z integracji, a błędne ceny z niespójnych danych. Przeniesienie tych samych reguł i danych do innego systemu zachowa źródło kłopotów.

Zapisz problemy jako obserwowalne sytuacje. Na przykład: import blokuje pracę panelu, aktualizacja ceny trwa zbyt długo, obsługa ręcznie poprawia dane każdego zamówienia. Następnie porównaj koszt naprawy obecnego rozwiązania z migracją. W obu wariantach powinien być określony rezultat oraz sposób jego sprawdzenia.

Migracja jest uzasadniona, jeśli docelowy system lepiej obsłuży potrzebne procesy, a korzyść równoważy koszt przeniesienia i późniejszego utrzymania. Sprawdź to na demonstracji najtrudniejszego scenariusza. Do uporządkowania kryteriów przyda się także porównanie PrestaShop i WooCommerce.

Co trzeba zinwentaryzować

Najpierw utwórz rejestr danych i funkcji. Przy każdej pozycji wskaż źródło, miejsce docelowe, metodę przeniesienia oraz sposób kontroli. Dopisz, czy dane są nadal zmieniane w działającym sklepie. To pozwoli rozdzielić pierwsze załadowanie katalogu od uzupełnienia zamówień i klientów tuż przed przełączeniem.

• Produkty, warianty, identyfikatory SKU i EAN, ceny, stany oraz powiązania między pozycjami.
• Kategorie, marki, atrybuty, zdjęcia, załączniki i opisy w poszczególnych językach.
• Konta klientów, adresy, grupy i informacje o zgodach, wraz z ich kontekstem.
• Zamówienia, pozycje, rabaty, płatności, statusy i numery dokumentów.
• Opinie, strony informacyjne, artykuły blogowe i materiały do pobrania.
• Kupony, karty podarunkowe, punkty lojalnościowe i dane rozszerzeń, jeśli są używane.

WooCommerce ma wbudowany eksport produktów do CSV, opisany w dokumentacji importera i eksportera. Taki plik jest źródłem danych produktowych, a nie kompletną kopią funkcjonalną sklepu. Dane zamówień, klientów i dodatkowych rozszerzeń wymagają osobnego rozwiązania oraz dopasowania do struktury PrestaShop.

Automatyzuj powtarzalne przenoszenie danych, ale ręcznie uzgodnij mapowanie pól i wyjątków. Sprawdź próbkę obejmującą również nietypowe rekordy: produkt bez zdjęcia, wielowariantowy zestaw, klienta z kilkoma adresami czy zamówienie częściowo zwrócone. Prosta zgodność liczby rekordów nie dowodzi, że zachowano ich znaczenie.

Historia zamówień i dokumenty

Zdecyduj, czy pełna historia ma trafić do nowego panelu, czy część pozostanie w zabezpieczonym archiwum. Każdy wariant musi pozwolić obsłudze odnaleźć wcześniejszy zakup i rozwiązać zgłoszenie klienta. Jeśli stary system zostaje do odczytu, ustal, kto będzie go utrzymywał, zabezpieczał i udostępniał uprawnionym pracownikom.

Nie przeliczaj historycznych zamówień według nowych cenników i aktualnych reguł podatkowych. Przenoszona historia powinna zachować wartości zapisane przy zakupie. Sprawdź sumy, rabaty, koszty dostawy i powiązania z płatnościami. Numer zamówienia w nowym systemie może różnić się od starego, dlatego potrzebne jest trwałe powiązanie identyfikatorów.

Dokumentów wystawionych w poprzednim systemie nie należy traktować jak nowych zamówień do ponownego zafakturowania. Uzgodnij sposób dostępu do oryginałów oraz zakres migracji z osobami odpowiedzialnymi za księgowość i obsługę. Sprawdź też, czy import historii nie uruchomi ponownie wiadomości, automatyzacji lub eksportu do ERP.

Adresy URL i widoczność w Google

Przed przenosinami zbierz adresy z mapy witryny, narzędzi analitycznych, Search Console i logów. Dla każdego ważnego URL-a określ nowy odpowiednik. Nie ograniczaj się do produktów: ruch może prowadzić do kategorii, poradników i starszych stron kampanii. Lista powinna powstać, zanim stary sklep przestanie być dostępny.

Google zaleca mapowanie adresów i trwałe przekierowania do odpowiadających im nowych stron. Masowe kierowanie wszystkiego na stronę główną może zostać potraktowane jako soft 404. Trzeba też zaktualizować linki wewnętrzne, wskazania kanoniczne i mapy witryny. Te zasady opisuje dokumentacja przenoszenia witryn Google.

Oddzielnie oceń filtry i paginację. Nie każdy technicznie dostępny adres powinien stać się osobną stroną docelową. Sprawdź, które widoki mają treść i znaczenie dla użytkownika, a które jedynie powielają katalog. Decyzje o indeksowaniu zapisuj świadomie, zamiast automatycznie odtwarzać wszystkie stare parametry.

Przed startem sprawdź próbkę oraz automatyczny raport odpowiedzi dla całej przygotowanej mapy. Przekierowanie powinno prowadzić do właściwej, działającej strony bez zbędnego łańcucha. Przy zmianie adresów widoczność może przejściowo falować; nie ma gwarancji identycznych pozycji. Warto ograniczyć jednoczesne zmiany treści i struktury, aby łatwiej ocenić skutki przenosin.

Różnice, których nie załatwi import

Wariant produktu musi zachować własny identyfikator, stan, cenę i powiązanie ze zdjęciami tam, gdzie są one odrębne. Nazwa „rozmiar” w dwóch systemach nie gwarantuje zgodności całej struktury. Sprawdź również jednostki, zestawy i produkty personalizowane. Konfiguracja wykonana przez wtyczkę może wymagać osobnego modułu lub przebudowy.

Podatki, rabaty i koszty dostawy porównaj na tych samych koszykach. Zwróć uwagę na zaokrąglenia oraz kolejność naliczania promocji. Zgodność ceny pojedynczego produktu nie wystarczy, jeśli rozbieżność pojawia się dopiero przy kilku pozycjach i kuponie obejmującym część zamówienia.

Konta klientów i hasła to dwa różne zadania. Przeniesienie adresu e-mail nie oznacza, że nowy system poprawnie zweryfikuje stary skrót hasła. Sprawdź rzeczywisty mechanizm uwierzytelniania obu instalacji. Jeśli zgodna migracja haseł nie jest dostępna, przygotuj bezpieczne ustawienie nowego hasła i jasną komunikację. Nie eksportuj ani nie przesyłaj haseł w postaci jawnej.

Blog może pozostać na WordPressie lub zostać przeniesiony do uzgodnionego narzędzia. Ta decyzja wpływa na adresy, menu, wyszukiwanie i pracę redakcji. Nie zakładaj, że docelowa platforma sklepu automatycznie odtworzy wszystkie funkcje obecnego serwisu.

Plan przełączenia sprzedaży

1. Uruchom zabezpieczone środowisko docelowe i odseparuj jego płatności, pocztę oraz integracje.
2. Wykonaj migrację próbną, zachowując raport błędów i mapę identyfikatorów.
3. Sprawdź dane oraz pełne procesy z udziałem osób obsługujących sklep.
4. Powtórz próbę na świeżych danych i zmierz czas potrzebny na końcowe operacje.
5. Ustal moment wstrzymania zmian i zamówień oraz sposób obsługi płatności w toku.
6. Przenieś brakujące dane, uruchom przekierowania i wykonaj test produkcyjny.
7. Potwierdź działanie monitoringu oraz gotowość zespołu do obsługi zgłoszeń.

Plan wycofania musi wskazywać granicę, do której prosty powrót jest możliwy. Gdy nowy sklep zacznie przyjmować zamówienia, odtworzenie starej bazy bez uzgodnienia danych może je zgubić. Ustal, kto podejmie decyzję i jak zabezpieczy transakcje przyjęte po przełączeniu.

Pierwsze dwa tygodnie po migracji

Codziennie kontroluj płatności, przekazywanie zamówień, aktualizacje stanów i zgłoszenia klientów. Błąd transakcyjny wymaga reakcji od razu. Nie czekaj na większą próbkę danych, jeśli operator pobiera pieniądze, a sklep nie zapisuje potwierdzenia.

Obserwuj również błędy 404, indeksowanie i ruch na ważnych stronach. Porównując konwersję, uwzględnij poprawność analityki oraz źródła ruchu. Spadek zarejestrowanych zakupów może wynikać z błędu pomiaru, ale trzeba to potwierdzić danymi zamówień. Oddziel obserwacje od hipotez i zapisuj wprowadzane poprawki.

Wyznacz osobę zbierającą zgłoszenia po starcie. Przy każdym zapisz adres, czynność, oczekiwany wynik i numer zamówienia, jeśli problem go dotyczy. Dzięki wspólnej liście obsługa i programiści nie będą równolegle wyjaśniać tego samego przypadku w kilku kanałach.

Najczęstsze pytania

Czy stracę pozycje w Google?

Nie można zagwarantować niezmiennych pozycji. Mapa adresów, odpowiednie przekierowania i kontrola indeksowania ograniczają ryzyko błędów technicznych. Zmiana treści lub struktury wymaga dodatkowej oceny.

Czy klienci zachowają swoje konta i hasła?

Konta można przenieść po uzgodnieniu mapowania danych. Zachowanie haseł zależy od zgodności mechanizmów i wybranego rozwiązania migracyjnego. Jeśli jej nie ma, zaplanuj ustawienie nowych haseł.

Ile trwa migracja sklepu?

Zależy od danych, integracji i różnic funkcjonalnych. Termin powinien uwzględniać migrację próbną, poprawki oraz testy obsługi. Sam import jest tylko jednym etapem.

Czy sklep musi być wyłączony przez cały czas?

Nie. Przygotowanie i większość prób odbywa się równolegle do sprzedaży. Na końcu trzeba uzgodnić krótki okres kontrolowanego przełączenia i spójne przeniesienie zmian.

Przed wyceną przygotuj listę danych, integracji i najtrudniejszych zamówień. Pozwoli ona określić rzeczywisty zakres migracji sklepu oraz sprawdzić, czy zmiana platformy jest opłacalna.

Artykuł Migracja z WooCommerce na PrestaShop: co trzeba przenieść pochodzi z serwisu eCommerce Expert.

Pierwsze 48 godzin: dostępy i kopia

Wyznacz jedną osobę, która zbierze informacje i będzie koordynować zmiany. Jeśli każdy pracownik osobno prosi o reset hasła albo zmienia ustawienia, łatwo stracić orientację. Przygotuj rejestr usług: nazwa, właściciel konta, adres logowania, kontakt do dostawcy, termin odnowienia i osoba mająca dostęp. Haseł nie zapisuj w ogólnodostępnym arkuszu.

Sprawdź domenę i DNS, hosting, panel sklepu, bazę danych, repozytorium, pocztę, operatorów płatności, integracje kurierskie oraz system ERP. Dołącz konta analityczne, narzędzia reklamowe i usługi przechowujące kopie. Dostęp administratora sklepu nie oznacza dostępu do serwera, a możliwość opłacenia hostingu nie musi oznaczać kontroli nad domeną.

Przy odzyskiwaniu kont korzystaj z oficjalnych procedur dostawców i dokumentów potwierdzających uprawnienia firmy. Najpierw sprawdź adresy oraz numery używane do odzyskiwania dostępu. Po uporządkowaniu sytuacji nadaj nowemu zespołowi oddzielne konta. Zmianę haseł i kluczy zaplanuj z uwzględnieniem usług, które ich używają, aby przypadkiem nie zatrzymać synchronizacji.

Wykonaj kopię plików i bazy przed większymi zmianami. Zabezpiecz również logi, konfigurację zadań cyklicznych i ustawienia serwera potrzebne do odtworzenia sklepu. Nie przechowuj archiwum w publicznym katalogu witryny. Jeśli nie masz dostępu technicznego, poproś hosting o zabezpieczenie danych w ramach przysługujących Ci uprawnień.

Co masz, a czego brakuje

Oddziel działającą wersję sklepu od materiałów potrzebnych do jego rozwoju. Na serwerze mogą być pliki PHP, lecz tylko zbudowane i pomniejszone pliki JavaScript oraz CSS. Brakować może źródeł motywu, konfiguracji narzędzi lub skryptu wdrożenia. Kopia serwera jest wtedy cenna, ale nie zastępuje kompletnego projektu.

Sprawdź repozytorium: czy zawiera ostatnią wdrożoną wersję, wszystkie własne moduły i historię zmian? Sam dostęp do pustego albo dawno nieaktualizowanego repozytorium nie wystarczy. Porównanie z produkcją pokaże, czy poprawki były robione bezpośrednio na serwerze i czy można je odtworzyć.

• Zbierz kod dedykowany, źródła motywu i instrukcję jego budowania.
• Odszukaj listę licencji, faktury i konta producentów rozszerzeń.
• Zabezpiecz opis integracji, zadań cyklicznych i automatycznych eksportów.
• Sprawdź, czy istnieje instrukcja wdrożenia i przywracania kopii.
• Zbierz otwarte zgłoszenia, zaakceptowane wymagania oraz niedokończone prace.

Przy brakach zapisz ich skutek. Brak dokumentacji modułu może oznaczać potrzebę analizy kodu. Brak źródeł części interfejsu może wymusić jej odtworzenie. Brak uprawnienia do pobrania aktualizacji dodatku wymaga kontaktu z producentem. Taki opis jest bardziej przydatny niż ogólna ocena, że poprzednia agencja zostawiła bałagan.

Jak ocenić stan sklepu

Nowy wykonawca powinien najpierw uruchomić kopię w odizolowanym środowisku. Trzeba ograniczyć dostęp, wyłączyć prawdziwą wysyłkę wiadomości i odłączyć automatyzacje tworzące dokumenty lub przesyłki. Dopiero na takiej kopii można sprawdzać aktualizacje i wpływ wyłączenia podejrzanych modułów.

Przegląd obejmuje wersję platformy i PHP, rozszerzenia, zmiany w rdzeniu, uprawnienia, kopie oraz sposób wdrażania. W PrestaShop osobnej uwagi wymagają override’y. Lista techniczna powinna zostać powiązana ze sprzedażą: która część odpowiada za ceny, dostępność, płatności i przekazanie zamówień.

Sprawdź zadania wykonywane w tle. Sklep może wyglądać poprawnie, choć od tygodnia nie aktualizuje stanów albo nie odbiera potwierdzeń. Dla każdej integracji ustal kierunek wymiany, częstotliwość, miejsce logów i osobę reagującą na błędy. Zwróć uwagę na procesy uruchamiane dotąd z infrastruktury poprzedniego wykonawcy.

Raport przejęcia powinien podzielić prace według skutków: pilne zagrożenia dla sprzedaży i danych, niezbędne działania utrzymaniowe oraz późniejszy rozwój. Przy każdej pozycji potrzebne są dowód, proponowany rezultat i szacunek z zaznaczoną niepewnością. Sam wiek sklepu nie uzasadnia budowy nowego systemu.

Sprawy formalne do wyjaśnienia

Zbierz umowę, zamówienia, protokoły odbioru, korespondencję i dokumenty licencyjne. Sprawdź, co uzgodniono w sprawie kodu, dostępu do źródeł, modyfikacji oraz przekazania po zakończeniu współpracy. Nie wyciągaj wniosku o prawach do całego projektu wyłącznie z faktury lub faktu korzystania ze sklepu.

Komponenty zewnętrzne mają własne warunki. Moduł kupiony przez agencję może wymagać przeniesienia konta, zmiany przypisania domeny albo nowej licencji; zależy to od zasad producenta i ustaleń z wykonawcą. Poproś o potwierdzenie dla konkretnego produktu. Ogólne zapewnienie, że „wszystko jest opłacone”, nie wyjaśnia dostępu do aktualizacji.

Jeśli trwa spór o kod lub odmowę wydania materiałów, przedstaw prawnikowi dokumenty i dokładną listę braków. Podstawowe regulacje zawiera ustawa o prawie autorskim, ale ocena uprawnień wymaga uwzględnienia konkretnej umowy. Techniczne zabezpieczenie sklepu i dochodzenie roszczeń to odrębne zadania.

Przekazanie bazy nowej firmie wymaga także uporządkowania zasad dostępu do danych osobowych. Zweryfikuj role, dokumentację powierzenia i sposób zakończenia dostępu poprzedniego wykonawcy z osobą odpowiedzialną za ochronę danych. Ustal postępowanie z kopiami roboczymi; obowiązki związane z zakończeniem usług omawia materiał UODO o powierzeniu przetwarzania. Nie przesyłaj pełnej bazy do kilku potencjalnych wykonawców tylko po to, by porównali wycenę.

Jak przygotować przekazanie nowemu zespołowi

Przygotuj krótki dokument opisujący działanie firmy i sklepu. Wymień najważniejsze procesy, terminy kampanii i ograniczenia wdrożeniowe. Dołącz kilka przykładów zamówień z nietypowymi warunkami. Osoba przejmująca sklep musi wiedzieć, jakie zachowanie ma zachować, a nie jedynie jak uruchomić aplikację.

Materiały uporządkuj w czterech grupach: kod i wdrożenia, usługi i dostępy, procesy biznesowe oraz lista problemów. Sekrety przekaż oddzielnie w menedżerze haseł. Każdemu dostępowi przypisz właściciela, a po zakończeniu przejęcia usuń zbędne uprawnienia i nieużywane klucze.

Ustal mierzalny koniec etapu przejęcia. Nowy zespół powinien umieć odtworzyć sklep, wykonać kontrolowane wdrożenie, znaleźć logi awarii i wskazać sposób kontaktu z dostawcami. Powinien również przedstawić listę braków, których jeszcze nie rozwiązano. Przejęcie nie musi oznaczać naprawienia wszystkich historycznych problemów jednocześnie.

Jak ograniczyć zależność od kolejnego wykonawcy

Własne konta i aktualna dokumentacja powinny być elementem zwykłej pracy, a nie pakietem przygotowywanym dopiero przy rozstaniu. Odbieraj kod oraz opis zmian po etapach. Sprawdzaj, czy wdrożona wersja znajduje się w repozytorium i czy wiadomo, jak ją odtworzyć.

Wyznacz po stronie firmy osobę odpowiedzialną za terminy odnowień i dostępów. Uzgodnij regularną próbę przywrócenia kopii oraz aktualizację listy integracji. Nawet dobry wykonawca może zmienić zespół, zakończyć usługę albo być czasowo niedostępny. Sklep powinien mieć udokumentowany sposób działania także w takiej sytuacji.

Przed nową umową wykorzystaj listę pytań do agencji e-commerce. Szczególnie dokładnie sprawdź warunki przekazania projektu i obsługi awarii po starcie.

Ustal także kanał kontaktu na czas przejęcia. Pracownicy powinni wiedzieć, komu zgłaszać brak zamówienia, błędną cenę lub niedziałającą wysyłkę i jakie dane dołączyć. Nowy wykonawca potrzebuje jednej listy zgłoszeń z priorytetami. Bez niej łatwo skupić się na widocznych drobiazgach, podczas gdy poważny problem integracyjny pozostaje w prywatnej korespondencji. Po pierwszym przeglądzie wspólnie zatwierdź kolejność napraw i termin ponownej oceny stanu sklepu.

Najczęstsze pytania

Wykonawca nie oddaje dostępów. Co mogę zrobić?

Zbierz dokumenty, określ brakujące konta i skorzystaj z oficjalnych procedur ich dostawców. Równolegle wyjaśnij z prawnikiem obowiązki wynikające z umowy. Nie próbuj uzyskiwać dostępu do cudzych kont poza procedurą autoryzacji.

Czy moduły kupione przez agencję są moje?

To zależy od licencji, sposobu zakupu i umowy. Sprawdź możliwość korzystania, aktualizacji oraz przekazania obsługi innemu wykonawcy. Potrzebne jest potwierdzenie dla konkretnego rozszerzenia.

Czy trzeba budować sklep od nowa?

Nie. Najpierw trzeba ocenić, czy można go odtworzyć, utrzymywać i rozwijać. Odbudowa może być uzasadniona, ale powinna wynikać z porównania kosztów i ograniczeń.

Ile trwa przejęcie sklepu?

Zależy od dostępów, dokumentacji i stopnia modyfikacji. Rozdziel zabezpieczenie bieżącej sprzedaży od pełnego rozpoznania projektu. Termin drugiego etapu można wiarygodnie ustalić po pierwszym przeglądzie.

Jeśli potrzebujesz pomocy, przygotuj listę dostępów, opis aktualnych problemów i informację o ostatniej kopii. To dobry punkt wyjścia do przejęcia i ustabilizowania sklepu.

Artykuł Sklep porzucony przez wykonawcę: od czego zacząć pochodzi z serwisu eCommerce Expert.

Wracam do tego projektu, bo dobrze pokazuje, jak zmieniła się moja praca. Znam jego zakres i pamiętam, na co poświęcaliśmy czas. Mogę więc porównać konkretne zadania z tym, jak podszedłbym do nich teraz.

Prosty katalog, sporo pracy pod spodem

Panel ekspertów PrestaShop to katalog certyfikowanych agencji. Właściciel sklepu przegląda ich profile, sprawdza specjalizacje i referencje, a następnie kontaktuje się z wybranym wykonawcą. Agencje zarządzają swoimi profilami i dbają o to, jak prezentują się na tle konkurencji.

Z perspektywy odwiedzającego zasada działania jest prosta. Przy budowie trzeba jednak zadbać o każdy etap: wprowadzanie danych, ich sprawdzanie, wyszukiwanie i prezentację wyników. Filtr wybrany na stronie musi odpowiadać parametrom w adresie i zapytaniu do bazy. Formularz powinien przyjąć poprawne dane i wychwycić błędne. Wszystko musi działać w różnych wersjach językowych.

Do tego dochodzi panel administracyjny. Użytkownik katalogu go nie widzi, ale jego wykonanie zajmowało tyle pracy co część publiczna. Właśnie takie zadania wypełniały nam kolejne tygodnie: potrzebne, często powtarzalne, a każde wymagające napisania i sprawdzenia kodu.

Trzy osoby oznaczały także czas na współpracę

Podział zadań pozwalał pracować równolegle, ale wymagał codziennych ustaleń. Czekaliśmy na przegląd kodu, uzgadnialiśmy rozwiązania i scalaliśmy zmiany, które powstawały w różnych częściach aplikacji. W harmonogramie ta współpraca wyglądała skromniej niż później w praktyce.

Dlatego trzy miesiące pracy trzech osób to znacznie więcej niż samo pisanie funkcji. W tym czasie mieściło się również wszystko, co było potrzebne, żeby z osobnych fragmentów powstała jedna działająca aplikacja.

Jak wyglądałaby ta praca dzisiaj

Przez ostatnie miesiące przygotowałem sobie zestaw narzędzi opartych na modelach językowych. Powierzam im dużą część powtarzalnej pracy programistycznej. Przy takim katalogu zacząłbym od opisania struktury danych i zasad działania, a następnie na tej podstawie tworzył szkielet aplikacji, migracje i panel administracyjny.

To zadania, przy których dziś myślę o dniach zamiast tygodni. Podobnie jest z formularzami, walidacją i wersjami językowymi: wspólny opis pozwala wygenerować powiązane fragmenty, które wcześniej trzeba było pisać osobno. Moja praca polega wtedy na sprawdzeniu, czy wynik odpowiada założeniom. Szczególnej uwagi wymagają miejsca, w których rozwiązanie odbiega od typowego schematu.

Zmieniło się też miejsce testów w całym procesie. Wcześniej zostawały na koniec, o ile wystarczyło czasu, a rzadko wystarczało. Teraz powstają razem z kodem. Do przeglądu mogę przejść od razu, bez oczekiwania na zakończenie zadania przez drugiego programistę.

Stąd mój szacunek: miesiąc samodzielnej pracy zamiast dziewięciu osobomiesięcy. Znaczna część tamtego wysiłku przypadała na czynności, które obecnie wykonują narzędzia. Przy pracy w pojedynkę odpada również czas potrzebny na koordynację trzech osób.

Co uwzględniam w tym miesiącu

Nadal musiałbym porozmawiać z ludźmi, którzy będą korzystać z panelu. Ustalić zawartość profilu agencji, uprawnienia do edycji i sposób wyszukiwania. Dobrym przykładem jest filtr kraju. Ma wskazywać siedzibę agencji czy rynek, który ona obsługuje? Oba warianty da się zaprogramować. Wybór zależy od tego, jak właściciel sklepu szuka wykonawcy.

Model może zaproponować odpowiedź, ale bez znajomości potrzeb użytkowników łatwo przyjąć błędne założenie. Szybsze napisanie kodu nie zwalnia mnie z podjęcia tej decyzji.

W szacowanym miesiącu uwzględniam także czytanie i sprawdzanie wygenerowanego kodu. Wymaga co najmniej takiej samej uwagi jak kod pisany ręcznie. Gotowo wyglądające rozwiązanie potrafi uśpić czujność, a za jego działanie nadal odpowiadam ja.

Co to porównanie mówi o wycenie projektu

Ten miesiąc jest moją oceną konkretnego, znanego mi projektu. Pokazuje, jak duże znaczenie dla kosztu wdrożenia ma sposób pracy wykonawcy. Przez lata liczyliśmy przede wszystkim czas potrzebny programistom na napisanie rozwiązania. Dziś przy powtarzalnych zadaniach ten nakład może być znacznie mniejszy.

Jeżeli zamawiasz podobny panel, poproś wykonawcę o wyjaśnienie, na co przeznaczy czas z wyceny. Jak korzysta z AI? Ile pracy przewiduje na ustalenie wymagań, a ile na sprawdzenie rezultatu? Z takiej rozmowy dowiesz się więcej niż z samej liczby godzin.

To porównanie skłoniło mnie też do szerszego spojrzenia na mój zawód i sposób rozliczania wdrożeń. Piszę o tym w artykule AI zmienia nasz świat.

Artykuł Projekt, na który mieliśmy trzy miesiące pochodzi z serwisu eCommerce Expert.

Co należało sprawdzić przed migracją

Przez lata w sklepie zainstalowano 40 modułów. Siedem miało zmieniony kod, a trzech nie rozwijali już producenci. Środowisko działało na PHP 7.1 u kresu wsparcia, co blokowało dalsze aktualizacje.

Klient rozmawiał wcześniej z dwiema agencjami. Obie proponowały nowy sklep i przewidywały około 40% spadku ruchu organicznego w pierwszym półroczu. Przy takim udziale Google w sprzedaży strata byłaby większa niż koszt wdrożenia.

Przez dekadę powstały tysiące adresów kategorii, filtrów, producentów i kampanii. Część nadal sprowadzała klientów, choć firma nie korzystała już aktywnie z tych stron. Trzeba było je odnaleźć i uwzględnić w nowej strukturze.

Inwentaryzacja adresów i modułów

Pierwsze dwa tygodnie przeznaczyłem na analizę, przed rozpoczęciem pisania kodu produkcyjnego. Połączyłem dane z Search Console, mapy witryny i logów serwera z ostatnich dwunastu miesięcy. Lista objęła 11 800 unikalnych adresów z przynajmniej jednym wejściem. Dla każdego określiłem stronę docelową.

Sprawdziłem również funkcję każdego z 40 modułów. 22 okazały się zbędne, w tym cztery powielały tę samą funkcję. Pozwoliło to ograniczyć liczbę elementów przenoszonych do nowego sklepu.

Przygotowanie nowej wersji

Przez jedenaście tygodni przygotowywałem sklep na PrestaShop 8.1 na oddzielnym środowisku. Skrypt migracyjny uruchamiałem wielokrotnie, żeby wykryć nietypowe przypadki w danych i sprawdzić ich obsługę. Ostatni przebieg przed przełączeniem, na świeżej kopii produkcji, trwał czterdzieści minut.

Mapa przekierowań 301 objęła wszystkie 11 800 adresów. Automatyczna kontrola po wdrożeniu sprawdziła odpowiedzi serwera, liczbę przekierowań po drodze i zawartość stron docelowych. Wykryła 340 adresów prowadzących do pustych kategorii. Poprawiłem je przed zgłoszeniem nowej mapy witryny.

Wyniki po przełączeniu

• Przerwa potrzebna do uruchomienia nowej wersji trwała 22 minuty.
• Największy dzienny spadek ruchu organicznego wyniósł 12% i wystąpił szóstego dnia po migracji.
• Po 17 dniach ruch wrócił do poziomu sprzed przeniesienia sklepu.
• Czas generowania strony kategorii zmniejszył się z 2,9 do 0,7 sekundy.
• Sklep korzystał z 18 modułów zamiast wcześniejszych 40.

Znaczenie przygotowania

Rozpoznanie starego sklepu zajęło znaczną część pracy. Lista działających funkcji i adresów pozwoliła zaplanować migrację, zanim zaczęło się wdrożenie. W tym projekcie właśnie te przygotowania pomogły ograniczyć ryzyko, którego obawiały się wcześniejsze agencje.

Artykuł Migracja hurtowni B2B z PrestaShop 1.6 na 8 pochodzi z serwisu eCommerce Expert.

Dlaczego ręczny test nie wykrył błędu

Pierwszą godzinę poświęciłem na kopię bazy i plików, a drugą na porównanie logów z trzech tygodni. Problem dotyczył jednej metody płatności, wybieranej przez 78% klientów.

W niedzielę w nocy automatycznie zaktualizował się moduł płatności. Nowa wersja zmieniła format odpowiedzi bramki. Sklep nie rozpoznawał potwierdzenia i pozostawiał zamówienie ze statusem „oczekujące na płatność”, mimo pobrania pieniędzy przez operatora.

Klient sprawdzał zakupy, wybierając przelew tradycyjny. Ta metoda działała, dlatego test nie ujawnił awarii. Cała diagnoza zajęła cztery godziny.

Poprawka i obsługa zamówień w toku

W ciągu kolejnych dwóch godzin dodałem obsługę nowego formatu oraz zgodność ze starym. Dzięki temu sklep mógł prawidłowo przetwarzać także wcześniejsze zamówienia. Odzyskałem 214 zamówień, które utknęły przez trzy dni. Klienci otrzymali wiadomość, również ci, którzy zdążyli już kupić produkty w innym sklepie.

Dlaczego zgłoszenie przyszło dopiero po trzech dniach

Sklep miał monitoring dostępności strony, czasu odpowiedzi i miejsca na dysku. Nie kontrolował jednak liczby zamówień. Strona pozostawała dostępna, więc działające powiadomienia nie sygnalizowały problemu ze sprzedażą.

Dodałem alert SMS porównujący liczbę zamówień z dwóch godzin ze średnią dla tego samego przedziału z poprzednich czterech tygodni. Powiadomienie uruchamia się po spadku poniżej 30% tej średniej. Przygotowanie monitoringu zajęło dzień pracy. Koszt trzech dni przestoju był ponad sto razy wyższy.

Co zmieniło się po interwencji

• Proces zakupowy działał prawidłowo sześć godzin po zgłoszeniu.
• Odzyskałem 214 zamówień zatrzymanych przez błąd płatności.
• Automatyczne aktualizacje modułów zastąpiła procedura sprawdzania zmian na kopii sklepu.
• Monitoring objął spadek liczby zamówień, a nie tylko dostępność strony.

Artykuł Awaria płatności po aktualizacji modułu pochodzi z serwisu eCommerce Expert.