Migracja i aktualizacja do PrestaShop 9: lista kontrolna

Jak byśmy do tego podeszli

W przypadku odpowiedniego sklepu PrestaShop 1.7 lub 8 z utrzymywanymi modułami i ograniczonymi zmianami najpierw przetestowalibyśmy aktualizację kopii na środowisku testowym. W przypadku sklepu 1.6, niewspieranego motywu lub rozległych zmian własnych zwykle zaczęlibyśmy od oceny świeżej instalacji PrestaShop 9 z mapowaną migracją danych. Przebudowa to ścieżka do oceny, a nie automatyczny wymóg dla każdego dostosowanego sklepu: jedną niedziałającą integrację często można dostosować lub zastąpić osobno, jak pokazuje poniższy przykład.

Usługa PrestaShop Upgrade Service zaczyna się od bezpłatnego sprawdzenia wersji, PHP, hostingu, motywu i modułów, zapewnia stałą pisemną wycenę przed pracami i jest realizowana na środowisku testowym, podczas gdy sklep produkcyjny nadal przyjmuje zamówienia; przejście z 1.6 jest migracją z wyższą wyceną.

Zanim zatwierdzisz którąkolwiek ścieżkę, poproś o wyniki analizy zgodności, zakres danych, kryteria odbioru i plan wycofania zmian.

Wybierz wspieraną wersję docelową i ścieżkę dopasowaną do sklepu

Duża migracja PrestaShop może zmienić PHP, komponenty frameworka, strony administracyjne, motywy i punkty rozszerzeń. Zinwentaryzuj konkretną instalację sklepu przed wyborem aktualizacji lub przebudowy. Zachowaj pisemną listę kryteriów odbioru i punkt decyzji o wycofaniu zmian.

Według stanu na 26 października 2026 r. PrestaShop 9.2 jest dostępny. Wybierz wersję z poprawkami, wspieraną przez dostawców płatności, wysyłki, motywu i integracji. Sklep, który nadal się ładuje, może mimo to pozostawać poza utrzymaniem oprogramowania.

Oficjalne utrzymanie PrestaShop 1.6 zakończyło się 30 czerwca 2019 r.; późniejsza praca wolontariuszy była osobną inicjatywą. Zobacz komunikat o utrzymaniu i wyjaśnienie utrzymania przez wolontariuszy. Regularne utrzymanie 1.7 zakończyło się wraz z wydaniem 9.0.

Aktualizator pierwszego etapu z 1.6 nie jest utrzymywany. Przećwicz go w izolacji i zachowaj migawkę na każdym etapie. Czysta przebudowa to osobna opcja, a nie dowód technicznej niemożliwości aktualizacji etapowej. Sprawdź oficjalne ścieżki Update Assistant.

Niezależnie od ocenianej ścieżki o jej przydatności decydują składanie zamówień, realizacja i odtwarzanie na środowisku testowym. Kopia, która się uruchamia i wyświetla katalog, jeszcze nie przeszła oceny.

Przygotowanie zmniejsza ryzyko, ale nie wyklucza błędów ani awarii infrastruktury. Nie obiecuj stałego czasu aktualizacji, przestoju ani odzyskania pozycji na podstawie liczby modułów lub wielkości katalogu i nie wybieraj ścieżki na podstawie obietnicy uniwersalnej zgodności.

Przykład: zachowaj sklep, zastąp przeszkodę

Załóżmy, że sklep na PrestaShop 8 ma utrzymywany motyw i działające narzędzia katalogowe, ale jego połączenie z przewoźnikiem napisane na zamówienie zawodzi w proponowanej wersji docelowej. Poproś programistę o wyodrębnienie tego połączenia, ustalenie wymagań danych i etykiet oraz przetestowanie dostosowania lub zamiennika na środowisku testowym. Samo to ustalenie nie uzasadnia przebudowy całego katalogu. Z kolei sklep 1.6 z niewspieranym motywem, bezpośrednimi zmianami rdzenia i nieudokumentowanym połączeniem magazynowym potrzebuje wycenionego porównania obu ścieżek przed rozpoczęciem prac.

Wymagaj opisu wybranej ścieżki na piśmie. Przy aktualizacji jest to sekwencja etapów z podaniem źródła, aktualizatora, wersji docelowej i środowiska PHP na każdym etapie oraz punktu kontrolnego, z którego można odtworzyć każdy etap (zobacz sekcję o zgodności PHP poniżej). Przy świeżej instalacji jest to mapa danych i procedura końcowego przeniesienia (zobacz sekcję o czystym sklepie poniżej).

Ustal uruchomioną wersję i wymagania serwera

Odczytaj wersję działającego sklepu w stopce panelu lub Parametry zaawansowane > Informacje. Potwierdź, że jesteś na produkcji, a nie starej kopii testowej. Wersja modułu nie jest wersją sklepu.

Starszy 1.6 zwykle definiuje _PS_VERSION_ w config/settings.inc.php. PrestaShop 1.7/8 udostępnia wersję aplikacji w app/AppKernel.php. W PrestaShop 9.1 ta klasa deleguje VERSION do src/Core/Version.php. Traktuj skopiowany plik jako wskazówkę, a nie dowód kompletnego wdrożenia.

W kodzie z już uruchomionym środowiskiem sklepu używaj _PS_VERSION_ i version_compare() do kontroli zgodności. Zapisz wersję PHP dla WWW oraz CLI, rozszerzenia, limity, wersję bazy, aktywny motyw i wersje modułów.

php -v
php -m
php -i | rg 'memory_limit|max_execution_time'
# Run through the actual database connection:
# SELECT VERSION();

mysql --version podaje wersję programu klienckiego, niekoniecznie podłączonego serwera. SELECT VERSION() wskazuje serwer osiągnięty przez dane połączenie. CLI PHP może się też różnić od puli PHP-FPM obsługującej sklep.

Dokumentacja PrestaShop 9 zaleca 512M pamięci na skrypt. Zapewnij zmierzony dodatkowy zapas dla dużych aktualizacji i zadań PDF/importu. Sprawdź CURL, DOM, Fileinfo, GD, Iconv, Intl, JSON, Mbstring, OpenSSL, PDO/MySQL, SimpleXML i Zip oraz wymagane ustawienia środowiska. Zobacz wymagania systemowe.

Gotowe wydania produkcyjne zawierają zależności. Composer i narzędzia budowania frontendu są potrzebne przy budowaniu ze źródeł, a nie przy każdej aktualizacji z pakietu.

Osobno sprawdź zgodność bazy i utrzymanie przez dostawcę. MySQL 8.0 przeszedł do Sustaining Support w kwietniu 2026 r.; nie traktuj go jako automatycznego wyboru dla nowego wdrożenia. Wybierz utrzymywane wydanie zgodne z dokładną wersją sklepu i stosem hostingu oraz przetestuj jego zachowanie SQL. Zobacz komunikaty o cyklu życia MySQL.

Zaplanuj zgodność PHP na każdym etapie

Poniżej znajduje się mapa zgodności, a nie zalecenie publicznego udostępniania starych wersji PHP:

Korzystaj ze starszej macierzy, macierzy PrestaShop 8 i wymagań 9.2 dla dokładnego źródła i celu.

PHP 7.4 zakończył cykl wsparcia 28 listopada 2022 r.; wsparcie bezpieczeństwa PHP 8.1 zakończyło się 31 grudnia 2025 r. Sprawdź wspierane gałęzie PHP i listę wersji po zakończeniu wsparcia. Zgodność nie czyni starego środowiska odpowiednim dla nowego publicznego wdrożenia.

1. Zapisz wymagania PHP dla sklepu źródłowego, aktualizatora, faz aktualizacji i wersji docelowej, w tym środowiska, które uruchamia importy i inne zadania cykliczne.
2. Wybierz bezpośrednią ścieżkę z 1.7 do 9 tylko wtedy, gdy dokładne wydanie Assistant i cel przechodzą kontrole wstępne oraz przećwiczono każdą fazę ze zgodnym PHP. Źródło i cel nie mają ogólnie wspólnej wspieranej wersji PHP; nie omijaj wymagań ani nie zakładaj automatycznego przełączenia środowiska.
3. Jeśli taka ścieżka nie zapewnia niezawodnego przejścia, wybierz sprawdzoną ścieżkę pośrednią lub czystą migrację.
4. Opcjonalny etap z 1.7.8 do 8.2 może działać na PHP 7.4; następnie 8.2 może działać na PHP 8.1 do sprawdzonego przejścia na 9. Te pośrednie środowiska po zakończeniu wsparcia utrzymuj w izolacji i tymczasowo.
5. Po osiągnięciu celu przełącz na wybraną utrzymywaną wersję PHP wspieraną przez cały stos i ponów testy.

Nie przełączaj produkcyjnej instalacji 1.7 na dowolne PHP 8 tylko dlatego, że hosting je oferuje, ani po to, by sprawdzić, czy stara instalacja się uruchomi: ustal to na środowisku testowym. Utrzymuj tę samą wersję dla WWW, CLI i zadań cyklicznych. Cofaj samo PHP tylko wtedy, gdy odtworzone pliki aplikacji i baza danych też są z nim zgodne.

Sprawdź moduły, własny kod i integracje

Zbuduj inwentarz z Menedżera modułów i wdrożonego systemu plików. Zapisz nazwę modułu, wersję, dostawcę, cel, powiązania ze sklepami, konfigurację, własność danych, zadania harmonogramu i zewnętrzne endpointy. Dla każdej pozycji wybierz zgodną aktualizację, zamiennik, usunięcie lub wyraźnie określone prace migracyjne.

Priorytetem są płatności, składanie zamówień, przewoźnicy, podatki, fakturowanie, ERP/PIM, zapasy, feedy i poczta. Ładujący się katalog nie dowodzi możliwości przyjmowania i realizowania zamówień.

• Odczytaj deklarowane przez każdy moduł zakresy wersji PrestaShop i PHP oraz ograniczenia zależności. Poproś dostawców motywu i modułów o potwierdzenie wsparcia dla dokładnej wersji docelowej i wydania PHP, a następnie przetestuj tę deklarację na swojej konfiguracji.
• Sprawdź własne override, skopiowane szablony, kontrolery na zamówienie, endpointy cron, klientów API, adresy callback i zakodowane na sztywno ścieżki panelu. Uwzględnij zmiany wprowadzone bezpośrednio w plikach rdzenia lub modułów.
• Sprawdź usunięte API i tłumaczenia względem dokładnej wersji docelowej, następnie odtwórz każdy błąd.
• Używaj generowanych linków i tras panelu zamiast sklejanych nazw katalogów i tokenów.
• Testuj klucze Webservice oraz nowszych klientów i zakresy Admin API jako oddzielne integracje.
• Wskaż osobę odpowiedzialną za każdą integrację, która może dostarczyć dane dostępowe do sandboxa, przypadki testowe i wsparcie przy uruchomieniu.

PrestaShop 8 używa Symfony 4.4; 9 używa Symfony 6.4. Nowoczesne strony panelu używają Twig i Symfony, a starsze kontrolery zachowują ścieżki zgodności. Nie zakładaj, że cykl renderowania lub nadpisanie szablonu starego kontrolera steruje zmigrowaną stroną.

Tools::displayPrice() usunięto w 9. Używaj formatPrice($amount, $currencyIsoCode) bieżących ustawień regionalnych we właściwym kontekście. Sprawdzaj stare wywołania tłumaczeń panelu i starsze metody cyklu życia osobno zamiast narzucać uniwersalny sposób przypisywania wartości w konstruktorze lub do właściwości.

Preferuj obsługiwane hooki, subskrybentów zdarzeń i dekorowanie usług Symfony tam, gdzie pasują. Starsze override klas nadal istnieją dla odpowiednich klas, ale mogą kolidować i wymagają sprawdzania sygnatur. Sprawdź parametry hooków, wykonanie i HTML sklepu w wybranym motywie. Zobacz poradnik struktury kodu.

Aktualizuj moduły na środowisku testowym w kontrolowanej kolejności. Zrób kopię danych przed odinstalowaniem lub resetowaniem czegokolwiek. Wyłączaj przez Menedżer modułów lub obsługiwaną akcję prestashop:module disable z docelowym kontekstem sklepu. Zmiana wyłącznie module.active nie obsługuje prawidłowo powiązań sklepów.

O co zapytać programistę lub agencję

• Które niezbędne moduły mają przetestowaną zgodną wersję, a które zależą od niewycenionych prac programistycznych lub nowej licencji?
• Które zmiany istnieją tylko we wdrożonych plikach, a nie w paczce dostawcy lub repozytorium kodu źródłowego?
• Kto przetestuje płatności, przesunięcia magazynowe, etykiety i eksporty księgowe z odpowiednimi dostawcami?
• Które środowisko uruchomieniowe obsługuje żądania przeglądarki, a które importy i inne zadania cykliczne?
• Jakie wyniki potwierdzą ukończenie i kto decyduje, czy nieudany test blokuje uruchomienie?

Przechowuj odpowiedzi razem ze spisem. Oznacz nieznanego dostawcę lub nieudokumentowaną integrację jako nierozstrzygniętą zależność, ze wskazaną osobą odpowiedzialną za jej zbadanie.

Jeśli korzystasz z naszych modułów, Module Updates & Remote Assist pokazuje zainstalowane wersje i dostępne aktualizacje w ramach Twojej licencji oraz pozwala wybierać instalacje i aktualizacje w panelu administracyjnym. Nie zastępuje to opisanej niżej spójnej kopii całego sklepu ani próby odtworzenia.

Utwórz spójne kopie i przećwicz migrację na środowisku testowym

Zanim zmienisz wersje, schemat, moduły lub motywy, wykonaj kopię zapasową całego sklepu i odpowiadającej mu bazy danych oraz zapisz, jak wrócić do pierwotnej instalacji. Uwzględnij pliki ukryte (zaczynające się od kropki), przesłane media, moduły, dane modułów, dostosowania motywu i konfigurację. Konfigurację serwera WWW i PHP-FPM, ustawienia SMTP, dane dostępowe płatności, adresy webhooków, zadania cykliczne i reguły CDN zapisz w chronionej dokumentacji operacyjnej.

Poniższy przykład zakłada chronioną ścieżkę logowania MySQL o nazwie shop-backup i istniejący katalog kopii z ograniczonym dostępem. Przed użyciem wybierz rzeczywistą nazwę bazy i ścieżki.

mysqldump --login-path=shop-backup --single-transaction --quick prestashop > /srv/backups/prestashop-before-update.sql
tar -C /var/www -czf /srv/backups/prestashop-before-update-files.tar.gz html

Sprawdź kod zakończenia polecenia, wolne miejsce i integralność archiwum. Zrzut transakcyjny wymaga tabel transakcyjnych i braku kolidujących zmian schematu. Skoordynuj migawkę plików i bazy oraz w razie potrzeby odpowiednio wstrzymaj zapis. Nie umieszczaj haseł w argumentach poleceń ani publicznych archiwach.

W Dockerze uwzględnij rzeczywiste trwałe montowania lub wolumeny oraz dane bazy lub zrzut logiczny. Zapisz wersje obrazu i środowiska oraz numerycznego właściciela. Skopiowanie samego obrazu kontenera nie zachowuje bieżących zamówień ani przesłanych plików.

1. Zachowaj kopię poza serwerem pod osobnymi danymi dostępowymi.
2. Przygotuj odizolowane miejsce docelowe, zanim uruchomi się skopiowana aplikacja lub jakiekolwiek zadanie cykliczne: osobną bazę danych, domenę i ograniczony dostęp. Wyłącz prawdziwe płatności, wychodzącą pocztę do klientów, produkcyjne webhooki i zaplanowane zapisy do systemów zewnętrznych albo skieruj je do połączeń sandbox i testowej skrzynki.
3. Odtwórz tam pliki i bazę danych. Potwierdź, że kopia rzeczywiście korzysta z testowej bazy danych i testowych miejsc docelowych, a nie tylko z innej domeny.
4. Sprawdź katalog, liczby zamówień, obrazy, logowanie klientów i reprezentatywne faktury.
5. Wykonaj zaplanowaną aktualizację lub migrację, łącznie z każdym przejściem PHP. Zachowaj komunikaty błędów i zapisz poprawki.
6. Powtórz całość od świeżej spójnej migawki, aby spisana procedura zawierała każdy wymagany krok.
7. Przećwicz też odtwarzanie: powrót do pierwotnej instalacji ze spójnych plików aplikacji, bazy danych, mediów, konfiguracji i zgodnego PHP.

Jeśli podczas próby zmieniasz konfigurację ręcznie, zapisz te zmiany w procedurze, aby kolejne odtworzenie nie połączyło się po cichu z produkcją.

Pliki kopii na dysku nie dowodzą możliwości odtworzenia, a liczby wierszy są przydatne, ale nie stanowią pełnego testu odtworzenia. Przetestuj rzeczywiste procesy i dostęp. Chroń wrażliwe dane klientów na środowisku testowym. Poradnik kopii zapasowych opisuje szerszy proces odtwarzania, a poradnik prywatnego środowiska testowego pomaga uporządkować kopię.

Wykonaj przećwiczony proces Update Assistant

Użyj aktualnego gotowego wydania Update Assistant zgodnego ze sklepem źródłowym, następnie wykonaj kontrole wstępne i proces wybranego celu. Obecne kanały i opcje różnią się od starszych zrzutów „1-Click Upgrade”. Wybór celu online zależy też od środowiska PHP.

Przed rozpoczęciem sprawdź wymagania i działania dotyczące modułów. Odróżnij tymczasowe wyłączenie od proponowanego odinstalowania lub resetu, które mogą usunąć ustawienia lub dane biznesowe. Zachowaj i zmigruj te dane przed zaakceptowaniem destrukcyjnego działania. Sprawdź proces Assistant i pomoc samego wydania.

Jak taka aktualizacja z PrestaShop 8 do 9 przebiega w praktyce i gdzie zacina się w działającym sklepie, pokazuje studium przypadku 4eck Media (po niemiecku).

Najpierw przećwicz dokładnie ten proces na środowisku testowym. Na produkcji powtórz spisaną procedurę zamiast improwizować:

1. Zaplanuj przećwiczone przełączenie i wyznacz operatora, listę kryteriów odbioru, moment decyzji o wycofaniu zmian oraz błędy, które je uruchamiają.
2. W Parametry sklepu > Ogólne > Przerwa techniczna ustaw Włącz sklep na Nie. Dodaj tylko zamierzone IP dostępu podczas konserwacji i przetestuj z adresu zewnętrznego.
3. Kontroluj też inne źródła zapisu: zadania cron, importy ERP, kolejki i callbacki. Sam tryb konserwacji nie zatrzymuje każdego zewnętrznego zapisu.
4. Wykonaj końcową spójną kopię zapasową i zapisz ostatni punkt uzgodnienia zamówień i płatności, oczekujące callbacki dostawców i importy w kolejce (zobacz sekcję o przełączeniu poniżej).
5. Wykonaj sprawdzoną ścieżkę Assistant i przejścia PHP. Monitoruj postęp i właściwe logi PHP oraz aplikacji.
6. Po błędzie zachowaj logi i zdiagnozuj dokładny krok. Nie odświeżaj, nie uruchamiaj ponownie ani nie zabijaj procesu na ślepo.
7. Po sukcesie odbuduj pamięci podręczne jako docelowy użytkownik środowiska i sprawdź właściciela wygenerowanych plików.
8. Włączaj zatwierdzone moduły w kontrolowanej kolejności i przed ponownym otwarciem przeprowadź testy odbiorcze, w tym składanie zamówień, pocztę, callbacki, przekierowania i ograniczenia indeksowania.

Polecenia CLI pamięci podręcznej dla zgodnej wersji docelowej obejmują:

php bin/console cache:clear --env=prod
php bin/console cache:warmup --env=prod

Użyj właściwego programu PHP i tożsamości. Napraw dostęp do wybranych ścieżek zapisu zamiast rekurencyjnie przekazywać cały kod produkcyjny użytkownikowi WWW. Utrzymuj blokadę zapisu podczas konserwacji do końca kontroli.

Zbuduj czysty sklep i zmapuj dane

Świeża instalacja docelowa przydaje się, gdy zastępujesz motyw 1.6, przeprojektowujesz sklep lub usuwasz nagromadzone dostosowania. Budujesz i testujesz ją na środowisku testowym, podczas gdy stary sklep nadal sprzedaje, więc blokady zapisu wymaga tylko końcowe przeniesienie. Powstaje jednak także projekt migracji danych: nie każdą tabelę, hasło, dokument czy integrację da się skopiować bez zmian.

1. Zainstaluj wspieraną wersję docelową w czystym, chronionym miejscu.
2. Wybierz zgodny motyw i zainstaluj wymagane zgodne moduły.
3. Skonfiguruj języki, waluty, podatki, przewoźników, płatności, pocztę i strony prawne.
4. Zmapuj kategorie, produkty, kombinacje, cechy, atrybuty, obrazy, stany magazynowe, ceny i metadane SEO.
5. Zmapuj klientów, adresy i grupy klientów, testując zachowanie haseł lub wymagany proces resetu.
6. Zmapuj historyczne zamówienia, faktury, korekty, płatności, numerację dokumentów i powiązania tam, gdzie są potrzebne do obsługi klienta lub księgowości.
7. Uwzględnij dane biznesowe poszczególnych modułów, powiązania ze sklepami i odwołania do integracji, a nie tylko tabele katalogu z rdzenia.
8. Sprawdź sumy, identyfikatory, powiązania, odwołania do obrazów i dostęp od strony klienta.

Natywny import CSV obsługuje wybrane encje katalogu i klientów; nie jest pełną migracją historycznych zamówień, płatności i dokumentów. Dedykowana usługa migracyjna lub skrypt wymaga jawnej mapy pól i relacji oraz przetestowanego przekształcenia.

Przykładowa mapa migracji

Zapytaj, jak ponowne uruchomienie migracji unika duplikowania rekordów i jak w końcowym przeniesieniu są obsługiwane zmienione lub usunięte rekordy źródłowe. Próba ma sens tylko wtedy, gdy tę samą procedurę można ponownie uruchomić na danych końcowych.

Nie odtwarzaj ręcznie wybranego zestawu tabel 1.6 na świeżym schemacie 9. Definicje tabel, wiersze sklepów i języków oraz identyfikatory różnią się. Zachowaj odwołania, relacje i numerację dokumentów prawnych procesem świadomym schematu.

Skróty haseł są jednokierunkowe. To, czy loginy będą działać dalej, zależy od narzędzia migracji, starszych kluczy i obsługi haszowania w wersji docelowej; samo skopiowanie wierszy klientów nie zapewnia ciągłości haseł. Przetestuj prawdziwe zmigrowane konta na odizolowanej instalacji docelowej. Jeśli resety są konieczne, użyj wspieranego procesu resetowania hasła i przed uruchomieniem uzgodnij jasną komunikację z klientami.

Końcowe przeniesienie zmian dokonanych od migawki próbnej następuje podczas przełączenia (zobacz poniżej); wymagaj jego spisanej procedury razem z mapą danych.

Zachowaj zgodny motyw lub utwórz motyw potomny

Aktualizacja rdzenia nie wymaga zawsze przejścia na Hummingbird. Classic pozostaje dostępny w odpowiednich wydaniach 9. Możesz zachować sprawdzony zgodny motyw oparty na Classic lub zaplanować osobną migrację motywu. Motyw 1.6 wymaga zastąpienia lub znacznego dostosowania do nowoczesnego PrestaShop.

Zachowaj zgodny motyw, jeśli przechodzi wymagane ścieżki zakupowe; sama aktualizacja rdzenia nie uzasadnia przeprojektowania. Traktuj przeprojektowanie jako osobno wycenianą pracę z własnymi kryteriami odbioru. Gdy obecny motyw nie może przejść do wersji docelowej, front sklepu jest przebudowywany na każdej ze ścieżek, co przemawia za oceną czystego sklepu.

Hummingbird stał się domyślny dla nowych instalacji 9.1. Używa Bootstrap 5.3 i właściwości niestandardowych CSS wraz z budowaniem SCSS. Zmiany zmiennych w czasie działania i zmiany wymagające procesu Sass/budowania to różne zadania. Testuj hooki, selektory, układy responsywne i HTML podmiotów trzecich.

W przypadku kupionego motywu zapytaj o dokładną zgodność z wersją docelową i PHP, ścieżkę aktualizacji, zakres licencji i obsługę modułów składania zamówień. Nie zakładaj, że motyw działa tylko dlatego, że jego szablony wyświetlają stronę główną. Przy zmianie motywu przetestuj katalog, pozycje modułów, elementy sterujące na telefonie i składanie zamówień na swoich prawdziwych produktach.

Kompletny punkt startowy motywu potomnego

Przykład zakłada zainstalowany Hummingbird i uruchamianie poleceń z katalogu głównego sklepu. Tworzy katalog konfiguracji, dziedziczy zasoby rodzica i jawnie rejestruje osobny arkusz potomny.

mkdir -p themes/shop-child/config themes/shop-child/assets/css themes/shop-child/templates
cp themes/hummingbird/preview.png themes/shop-child/preview.png

Utwórz themes/shop-child/config/theme.yml:

parent: hummingbird
name: shop-child
display_name: Shop Child
version: 1.0.0
author:
  name: Shop Team
assets:
  use_parent_assets: true
  css:
    all:
      - id: shop-child-overrides
        path: assets/css/shop-overrides.css
        media: all
        priority: 1100

Utwórz themes/shop-child/assets/css/shop-overrides.css:

body { --shop-child-ready: 1; }

Włącz motyw potomny w Wygląd > Szablon i logo. Odbuduj pamięci podręczne, otwórz panel Network przeglądarki i potwierdź, że zasoby rodzica i shop-overrides.css zwracają 200. Sprawdź obliczoną właściwość niestandardową --shop-child-ready na body. Potwierdza to ładowanie arkusza przed dodaniem rzeczywistych zmian wyglądu.

Kopiuj tylko szablony wymagające zmiany, zachowując ich ścieżkę w templates/. Porównuj je później z aktualizacjami rodzica. Zobacz strukturę motywu potomnego i poradnik motywu potomnego.

Zachowaj adresy URL, ustawienia indeksowania i zewnętrzne callbacki

Zbuduj spis starych adresów URL na podstawie katalogu, crawli, map witryny, logów i danych z Search Console. Przykłady indeksowania w Search Console nie są pełnym eksportem wszystkich zaindeksowanych URL. Uwzględnij wzorce URL kontrolowane przez moduły, aby zmiana trasy po cichu nie zepsuła adresów, z których już korzystają klienci lub systemy zewnętrzne.

W miarę możliwości zachowaj działające URL. Dla zmienionych odpowiedników używaj sprawdzonych przekierowań stałych, takich jak 301 lub 308. Sprawdź treść docelową, tagi canonical, linki wewnętrzne, alternatywy językowe i feedy. Nie przekierowuj niepowiązanych usuniętych stron na stronę główną ani nie obiecuj stałego okresu odzyskania wyników.

Użyj modułu mapy witryny, takiego jak gsitemap, lub innego wdrożonego generatora; aktualizacja rdzenia sama nie ustanawia pełnego procesu map XML. Przed przesłaniem sprawdź działające, indeksowalne kanoniczne URL. Usuń ograniczenia noindex i uwierzytelniania środowiska testowego tylko na zamierzonym celu produkcyjnym.

Na przykład otwórz stary adres produktu w każdym odpowiednim języku i przejdź za przekierowaniem do odpowiadającego mu produktu na produkcji. Sprawdź końcowy adres kanoniczny, linki językowe i wpis w mapie witryny. Upewnij się, że miejsce docelowe na produkcji nie ma już ograniczeń dostępu ani ustawienia noindex ze środowiska testowego, a kopia testowa nadal pozostaje chroniona.

Jeśli zmienia się domena lub ścieżka, zaktualizuj webhooki i IPN płatności, endpointy ERP, adresy feedów, pocztę, śledzenie przesyłek i zadania cykliczne. Testuj operacje wymagające uwierzytelnienia, zamiast traktować sam kod HTTP 200 jako dowód, że zadanie cron wykonało swoje zadanie biznesowe.

Poradnik adresów URL i przekierowań zawiera mapę, przykłady serwera i kontrole uruchomienia.

SEO Revolution obsługuje procesy przekierowań i map witryny; konfigurację opisuje jego pomoc modułu.

Smart SEO Friendly URL Manager obsługuje własne trasy i historię URL; skorzystaj z jego pomocy modułu, gdy zachowujesz lub zmieniasz te wzorce.

Przetestuj sklep przed ponownym otwarciem

Przeprowadź te kontrole przy każdej próbie na środowisku testowym i ponownie na docelowym środowisku produkcyjnym przed ponownym otwarciem. Dla każdego obszaru zbieraj dowody, a nie wrażenia.

Sprawdź obciążenie płatności w panelu dostawcy, a nie tylko status zamówienia. Potwierdź oczekiwane faktury, e-maile i zmiany stanów magazynowych oraz unikaj niezamierzonych podwójnych obciążeń. Tam, gdzie to możliwe, korzystaj z sandboxów dostawców; każdą kontrolowaną transakcję produkcyjną o niskiej wartości uzgodnij i rozlicz, aby testy nie powodowały niezamierzonych obciążeń, wysyłek ani wiadomości do klientów.

Zamień listę kontrolną w realistyczne koszyki

• Użyj koszyka gościa i istniejącego klienta, uwzględniając odpowiednią cenę grupową, kupon i miejsce dostawy. Porównaj podatki i koszty dostawy ze źródłem w tych samych warunkach.
• Przetestuj koszyki po obu stronach skonfigurowanego progu darmowej dostawy lub rabatu. Uwzględnij mieszane stawki podatkowe lub klientów firmowych tam, gdzie sklep ich obsługuje.
• Dokończ płatność sandbox, wyjdź przed powrotem do sklepu i potwierdź, że callback dostawcy nadal ustawia oczekiwany status zamówienia. Powtórz callback wspieranymi narzędziami testowymi dostawcy i sprawdź duplikaty zamówień, wiadomości lub zmian stanów magazynowych.
• Przeprowadź zwrot według uzgodnionego procesu i sprawdź rekord dostawcy, dokument korygujący i sposób obsługi stanu magazynowego. Sama zmiana statusu zamówienia nie dowodzi zwrotu pieniędzy.

Dla każdego przypadku zapisz koszyk początkowy, oczekiwany wynik, zaobserwowany rezultat i potwierdzenie. Poproś pracowników realizujących zamówienia o odbiór ich własnego procesu.

Zachowuj logi przez pierwsze pełne cykle operacyjne: zaplanowane importy, rozliczenia, zwroty i szczyt ruchu mogą ujawnić przypadki pominięte przy uruchomieniu. Porównuj skuteczność składania zamówień, pobieranie przychodów, kolejki obsługi i kluczowe strony wejścia z punktem odniesienia.

Przełącz sklep w jednym zaplanowanym oknie

Sprzedawaj dalej podczas przygotowań i prób; kontrolowanej przerwy w zapisach wymaga tylko końcowe przełączenie. Przeprowadź je jako osobną, przećwiczoną procedurę z operatorem, listą kryteriów odbioru i z góry uzgodnionymi warunkami błędu, które uruchamiają wycofanie zmian.

1. Zatrzymaj składanie zamówień w starym sklepie i zablokuj pozostałe źródła zapisu: tryb konserwacji oraz zadania cron, importy, kolejki i callbacki, jak w krokach 2 i 3 procesu Update Assistant powyżej. Dotyczy to również starego sklepu na ścieżce świeżej instalacji.
2. Zapisz punkt uzgodnienia: ostatnie uzgodnione zamówienie i zdarzenie płatności, oczekujące callbacki dostawców, importy w kolejce i zmiany stanów magazynowych. Uzgodnij z każdym dostawcą, gdzie opóźnione zdarzenia zostaną odebrane lub ponowione i kto je sprawdzi, zamiast blokować callbacki na ślepo.
3. Wykonaj końcową spójną kopię zapasową.
4. Ścieżka aktualizacji: zastosuj przećwiczoną procedurę do tego końcowego stanu produkcji albo użyj osobno przećwiczonej metody przeniesienia, która zachowuje wszystkie zmiany z międzyczasu. Nie promuj starej testowej bazy danych bez zmian: brakuje w niej każdego zamówienia przyjętego od migawki próbnej.
5. Ścieżka świeżej instalacji: przenieś końcową różnicę od migawki próbnej (zamówienia, klientów, stany magazynowe, płatności i zmienione dane modułów) i uzgodnij ją ze źródłem.
6. Przed przełączeniem wykonaj wszystkie możliwe kontrole wersji docelowej. Przełącz środowisko produkcyjne według przećwiczonej procedury, a następnie przed ponownym otwarciem składania zamówień sprawdź składanie zamówień, pocztę, callbacki dostawców, przekierowania i ustawienia indeksowania przez trasy produkcyjne. Osobną kopię testową utrzymuj pod ochroną.
7. Jeśli po przeniesieniu pozostaje osobna stara instalacja, utrzymuj ją w izolacji i w trybie tylko do odczytu dla upoważnionych osób. Przy aktualizacji w miejscu zachowaj spójną migawkę sprzed aktualizacji i przetestowaną procedurę odtworzenia. Pozostaw możliwość zapisu tylko w wybranym produkcyjnym procesie składania zamówień; ponowne otwarcie obu, aby uniknąć uzgadniania, tworzy dwa konkurujące strumienie zamówień.
8. Monitoruj sklep przez odpowiednie cykle importu, realizacji zamówień i płatności.

Zdiagnozuj typowe problemy po aktualizacji

Zacznij od pierwszej bezpiecznej kontroli: zachowaj dowody i odtwórz problem na chronionym środowisku testowym z zamierzonym środowiskiem uruchomieniowym i rozszerzeniami, zanim zmienisz sklep produkcyjny.

• Biała strona lub błąd 500: najpierw sprawdź logi serwera WWW, PHP-FPM i PrestaShop i zachowaj wyjątek. Na chronionym środowisku testowym tymczasowo włącz tryb debugowania, aby zidentyfikować wyjątek, a potem go wyłącz. Sprawdź rozszerzenia, pamięć, niezgodny kod i ścieżki zapisu.
• Błędy przepisywania: zachowaj własne reguły i sprawdź moduły Apache/AllowOverride lub lokalizacje Nginx. Testuj zmiany reguł we właściwym kontekście; usunięcie .htaccess z publicznego sklepu może też usunąć zabezpieczenia.
• Konflikt modułów: używaj wspieranych akcji wyłączania modułów i izoluj zmiany na kopii. Nie uruchamiaj globalnej aktualizacji SQL pola active z odgadniętą listą modułów natywnych i nie resetuj ani nie odinstalowuj modułów podczas aktualizacji produkcji bez kopii zapasowej, odtworzenia problemu na środowisku testowym i planu wycofania zmian.
• Brakujące tłumaczenia: sprawdź nazwy domen tłumaczeń, pliki i katalogi tłumaczeń, kontekst języka i sklepu oraz pamięci podręczne. Ponowna instalacja nie jest ogólną naprawą tłumaczeń i może usunąć dane modułu.
• Nieaktualne CSS lub JavaScript: najpierw sprawdź adresy URL zasobów, następnie odbuduj pamięci podręczne aplikacji i motywu i wyczyść odpowiednią pamięć podręczną CDN lub przeglądarki.
• Brakujące obrazy: sprawdź adresy zasobów, ścieżki i uprawnienia, zanim cokolwiek wygenerujesz ponownie, a następnie w razie potrzeby wygeneruj ponownie wymagany zakres miniatur. CDN sprawdź osobno.
• Logowanie do panelu: sprawdź URL, ciasteczka, HTTPS, stan konta pracownika, logi uwierzytelniania i doręczanie e-maili resetujących. Użyj wbudowanego procesu resetowania hasła pracownika.

Rdzeń PrestaShop używa usługi Crypto Hashing, w tym bcrypt i weryfikacji starszych MD5. Nie przypisuj całej obsługi haseł sklepu do MigratingPasswordHasher Symfony. Nowoczesne uwierzytelnianie panelu i ciasteczka sklepu używają różnych mechanizmów.

W tym rdzeniu nie ma standardowego polecenia odzyskiwania prestashop:user:change-password. Unikaj bezpośredniego SQL dla haseł i publicznych skryptów resetujących. Jeśli e-mail resetujący zawodzi, napraw doręczanie lub użyj konkretnie wspieranej administracyjnej procedury odzyskiwania.

Do szczegółowej diagnozy użyj poradnika rozwiązywania problemów.

Bezpiecznie odtwórz sklep i przekaż wynik

Przed rozpoczęciem ustal, jaka awaria uruchamia wycofanie zmian. Zachowaj logi i stan po błędzie do diagnozy. Odtworzenie musi łączyć odpowiadające sobie pliki, bazę, środowisko PHP, konfigurację i trwałe media.

1. Utrzymuj sklep w konserwacji i kontroluj zewnętrzne źródła zapisu.
2. Sprawdź, czy przetestowany proces odtwarzania Assistant może użyć zamierzonej kopii sprzed aktualizacji.
3. Do ręcznego odtworzenia użyj czystego miejsca docelowego i osobnej pustej bazy.
4. Odtwórz pełną spójną migawkę, w tym pliki ukryte. Nie nakładaj archiwum na zaktualizowany kod ani nie zakładaj, że rm -rf /var/www/html/* usunęło pliki zaczynające się od kropki.
5. Skieruj odtworzone środowisko do jego bazy i właściwej domeny oraz środowiska wykonawczego, napraw wymagane uprawnienia i odbuduj wygenerowane pamięci podręczne.
6. Przed ponownym otwarciem uzgodnij wszystkie zamówienia, płatności lub zdarzenia zewnętrzne przyjęte po wykonaniu migawki. Odtworzenie wczorajszej kopii po przyjęciu nowych zamówień wymaga jawnego planu uzgodnienia: odtworzenie nie wymazuje transakcji u dostawcy ani operacji w magazynie.
7. Przetestuj logowanie, katalog, składanie zamówień, pocztę i integracje według listy odtwarzania.

Wycofanie samej bazy przy nowych plikach pozostawia mieszaną instalację. Jeśli PHP się zmieniło, przywróć też zgodne wersje obsługujące WWW i CLI. Zachowaj środowisko po błędzie w izolacji, aż uzyskasz logi i dane potrzebne do zbadania.

Bez odpowiedniej kopii natychmiast zapytaj hosting o migawki i retencję, sprawdź inwentarz kopii Assistant i oceń odtwarzanie do punktu w czasie tam, gdzie istnieją logi binarne. Nie można bezpiecznie cofnąć nieudanej aktualizacji, kopiując kilka starych plików. Może być potrzebne specjalistyczne odzyskiwanie lub naprawa bieżącej wersji.

Po odtworzeniu powtórz wadliwy krok na środowisku testowym i napraw go przed ponowieniem na produkcji.

Ustal, kto powinien wykonać migrację

Wybierz pracę wewnętrzną lub specjalistę na podstawie złożoności rzeczywistego sklepu, swojej zdolności odtworzenia i kosztu zakłócenia. Poproś programistę o pisemny inwentarz, mapę danych i URL, przećwiczoną ścieżkę, testy odbiorcze, plan wycofania zmian i przekazanie monitoringu. Wyceny i szacunki przestoju oprzyj na tym zakresie zamiast ogólnych widełek rynkowych.

Przy przekazaniu udokumentuj nowe wersje, środowisko uruchomieniowe, motywy, zmienione ustawienia, właścicieli danych dostępowych, zadania, adresy URL integracji i ich właścicieli, znane ograniczenia, kroki odtwarzania z kopii i odpowiedzialność za wsparcie. Potwierdź, że wyświetlanie informacji debugowania na produkcji jest wyłączone, a tymczasowe narzędzia i dostępy zostały usunięte.