O migracji do nowej wersji głównej rzadko decyduje rdzeń PrestaShop, który w większości przypadków aktualizuje się poprawnie. Decydują o niej wasze moduły. W sklepie, który ma ich czterdzieści, wystarczy jeden dotykający procesu zamówienia i niezgodny z nową wersją, żeby zablokować całą migrację.
Audyt modułów musi więc wyprzedzić wszystko inne, łącznie z wyceną.
Co się naprawdę zmienia
PrestaShop 9 opiera się na nowszych wersjach PHP i Symfony, co powoduje trzy rodziny awarii.
Awarie związane z PHP. Ostrzejsze typowanie, wycofane właściwości dynamiczne, usunięte funkcje. Moduł napisany pięć lat temu i nigdy nie poprawiany generuje błędy krytyczne, a nie ostrzeżenia.
Awarie związane z frameworkiem. Moduły rozszerzające kontrolery Symfony albo deklarujące serwisy muszą nadążyć za nową wersją. Dotyczy to modułów nowych i dobrze zbudowanych, paradoksalnie bardziej narażonych niż te czysto legacy.
Awarie właściwe dla PrestaShop. Metody usunięte z historycznych klas, wycofane lub przemianowane hooki, zmiany w szablonach motywu domyślnego.
Inwentaryzacja, pierwszy efekt pracy
Zanim cokolwiek ruszycie, przygotujcie tabelę z jednym wierszem na moduł i sześcioma kolumnami.
- Nazwa techniczna i zainstalowana wersja.
- Dostawca i to, czy nadal istnieje. Dostawca, który zniknął, oznacza moduł bez przyszłości.
- Data ostatniej dostępnej aktualizacji. Powyżej osiemnastu miesięcy bez publikacji traktujcie moduł jako porzucony, dopóki nie zostanie udowodnione inaczej.
- Deklarowana zgodność z wersją docelową, z rozróżnieniem na to, co pisze strona produktu, i na to, co faktycznie przetestowano.
- Krytyczność: czy moduł dotyka płatności, procesu zamówienia, katalogu, czy tylko drugorzędnego elementu wyświetlania?
- Obecność nadpisań, widoczna w katalogu override. To najlepszy wskaźnik kruchości.
Tabelę wypełnia się w pół dnia i to ona wyznacza całą resztę projektu.
Cztery kategorie
Każdy moduł trafia do jednej z nich, a postępowanie jest inne.
Zgodny i utrzymywany. Aktualizujecie i testujecie. Przypadek najprostszy i rzadko stanowiący większość.
Zgodność zadeklarowana, ale niesprawdzona. Wzmianka na stronie produktu nie zastępuje odbioru. Te moduły trzeba testować w pierwszej kolejności, bo niezgodność wykryta późno kosztuje przesunięcie terminu.
Porzucony. Dwa wyjścia: znaleźć zamiennik albo zlecić przejęcie kodu. Przejęcie ma sens tylko wtedy, gdy funkcja jest specyficzna dla waszej działalności.
Zastępowalny funkcją rdzenia. Kategoria systematycznie niedoceniana. Każda wersja główna wchłania funkcje, które wcześniej wymagały modułu. Migracja to dobry moment, żeby odinstalować to, co przestało być potrzebne.
W rzeczywistych audytach ten ostatni przegląd usuwa z listy zwykle od pięciu do dziesięciu modułów, co odpowiednio odchudza projekt.
Kontrola Martwych Linków PrestaShop 8 i 9: Uszkodzone Linki i Brakujące ObrazyZnajdź martwe linki i uszkodzone obrazy przed swoimi klientami€59,00
Najczęstsze pułapki techniczne
Dla programistów i agencji cztery awarie wracają stale na modułach wymagających poprawek.
Metoda tłumaczenia dostępna bezpośrednio na kontrolerach zniknęła: trzeba przejść przez instancję modułu. Nadpisania metod, których sygnatura się zmieniła, generują błędy zgodności, zwłaszcza na metodach renderowania używanych do odpowiedzi asynchronicznych. Wywołania asynchroniczne do historycznych kontrolerów administracyjnych zmieniły postać i wymagają innego przekazywania parametrów. A moduły, które pisały bezpośrednio do tabel rdzenia, zderzają się ze zmianami schematu.
Żadna z tych poprawek nie jest sama w sobie złożona. Koszt bierze się z liczby.
Środowisko testowe
Nie podlega negocjacji, a mimo to regularnie się je pomija.
Musi opierać się na świeżej kopii bazy produkcyjnej, nie na zestawie demonstracyjnym. Większość niezgodności ujawnia się na prawdziwych danych: produkty ze stoma kombinacjami, klienci z niekompletnymi adresami, zamówienia w zapomnianych statusach.
Dwie ostrożności: zanonimizujcie dane klientów przed skopiowaniem i wyłączcie wszelką wysyłkę maili z tego środowiska. Test migracji, który wysyła dwa tysiące maili o zmianie statusu do prawdziwych klientów, to historia prawdziwa i częsta.
Plan testów
Testujcie ścieżki, nie strony. Sześć ścieżek pokrywa to, co istotne.
Pełne zamówienie jako niezalogowany odwiedzający, z realną płatnością w trybie testowym. Zamówienie z istniejącym kontem i zapisanym adresem. Dodanie do koszyka ze strony kategorii z aktywnymi filtrami. Wyszukiwanie wewnętrzne zakończone zakupem. Zwrot albo zgłoszenie posprzedażowe. A po stronie administracji: utworzenie produktu z kombinacjami i zatwierdzenie zamówienia.
Każdą ścieżkę trzeba przejść na komputerze i na telefonie. Liczcie jeden dzień na całość, do powtórzenia po każdej istotnej poprawce.
Przełączenie i to, co po nim
Zaplanujcie migrację poza okresami handlowymi, z określonym i przetestowanym oknem powrotu. Kopia zapasowa, której nigdy nie przywrócono, się nie liczy.
W kolejnych dniach liczą się trzy kontrole. Dzienniki błędów serwera, które ujawniają niezgodności nienapotkane na testach. Zepsute linki i brakujące obrazy, bo zmiana wersji może wpłynąć na ścieżki obrazów i przepisane adresy URL. Oraz napływ zamówień w porównaniu ze zwykłym poziomem: nagły spadek sygnalizuje blokadę w procesie zamówienia, której nikt nie zgłosił.
W tym ostatnim punkcie Weryfikator Martwych Linków dla PrestaShop przydaje się zarówno na etapie odbioru, jak i po przełączeniu: wykrywa zepsute linki wewnętrzne i brakujące obrazy, które mogła spowodować migracja, na PrestaShop 8 i na PrestaShop 9.