Optymalizacja modułów PrestaShop: override’y, konflikty i porządek w kodzie

Optymalizacja modułów PrestaShop nie ma bezpośredniego przełożenia na konwersję i właśnie dlatego bywa odkładana. Jej koszt widać gdzie indziej: w czasie, jaki zajmuje każda kolejna zmiana w sklepie, i w liczbie rzeczy, które psują się przy okazji. Sklep, w którym dołożenie pola do formularza zamówienia wymaga tygodnia i testów całej ścieżki zakupowej, płaci ten koszt co miesiąc, tylko nikt go tak nie księguje.

Ten tekst pokazuje, jak zinwentaryzować warstwę modułów i modyfikacji, jak ocenić, co realnie kosztuje, i jak uporządkować to bez zatrzymywania sprzedaży.

Trzy sposoby rozszerzania PrestaShop i ich konsekwencje

PrestaShop daje kilka dróg do zmiany zachowania sklepu i różnią się one nie tyle trudnością, co kosztem utrzymania. Wybór drogi zapada zwykle pod presją terminu, a rachunek przychodzi przy pierwszej aktualizacji.

Hooki są mechanizmem, dla którego ta architektura powstała: rdzeń wywołuje w określonych miejscach kod modułów, a moduły nie wiedzą o sobie nawzajem. Override rozwiązuje przypadki, w których potrzebna zmiana leży poza jakimkolwiek hookiem, i jest akceptowalny, o ile wiadomo, że istnieje. Modyfikacja w rdzeniu jest decyzją, którą podejmuje się świadomie i dokumentuje, bo inaczej kolejny wykonawca odkryje ją w najgorszym możliwym momencie. Mechanizmy i ich ograniczenia opisuje dokumentacja deweloperska PrestaShop.

Optymalizacja modułów PrestaShop zaczyna się od inwentaryzacji

Bez spisu każda rozmowa o porządkach jest rozmową o wrażeniach. Cztery zestawienia dają pełny obraz stanu.

Lista modułów z metrykami

Nazwa, wersja, data ostatniej aktualizacji, status włączenia oraz informacja, czy moduł jest wpięty w jakikolwiek aktywny hook. Ostatnia kolumna jest tą, dla której robisz to zestawienie: moduł wyłączony nadal zajmuje miejsce, ale nie wykonuje kodu, natomiast moduł włączony i niewpięty w nic wykonuje kod inicjalizacji na każdym żądaniu bez żadnego efektu.

Zawartość katalogu override

Lista plików z datą modyfikacji i wskazaniem, którą klasę i którą metodę nadpisują. To miejsce, w którym najczęściej znajduje się kod napisany przez wykonawcę, z którym firma już nie współpracuje, i którego nikt od tamtego czasu nie czytał.

Szablony nadpisane w motywie

Motyw może nadpisywać szablony rdzenia i szablony modułów. Te drugie są pułapką: aktualizacja modułu zmienia jego logikę, a szablon w motywie zostaje stary i przestaje pasować. Objawia się to jako brakujący element na stronie po aktualizacji, której nikt nie łączy z przyczyną.

Różnice względem czystego rdzenia

Porównanie plików sklepu z plikami tej samej wersji PrestaShop pobranej ze źródła. Operacja mechaniczna, a jej wynik bywa najbardziej pouczającym dokumentem w całym audycie. Jeśli lista różnic jest pusta, aktualizacja wersji jest zadaniem rutynowym. Jeśli zawiera kilkadziesiąt plików, jest projektem.

Które moduły realnie kosztują

Liczba modułów sama w sobie nic nie mówi. Sklep z sześćdziesięcioma dobrze napisanymi modułami działa szybciej niż sklep z dwudziestoma, z których trzy odpytują zewnętrzne usługi przy każdym wyświetleniu strony.

Wzorce, które kosztują najwięcej:

• Zapytanie do zewnętrznej usługi w trakcie generowania strony. Sklep czeka na odpowiedź, a jeśli usługa nie odpowiada, strona ładuje się aż do przekroczenia limitu czasu. Takie odpytania należą do zadań w tle, nie do żądania klienta.
• Zapytania do bazy w pętli po produktach. Widoczne na listingach: moduł dokłada jedno zapytanie na produkt, więc listing z pięćdziesięcioma pozycjami generuje pięćdziesiąt dodatkowych zapytań.
• Własne pliki stylów i skryptów ładowane na każdej stronie. Moduł obsługujący wyłącznie checkout dokładający swoje zasoby do strony głównej to typowy przypadek.
• Moduły omijające cache. Element wyświetlający treść zależną od użytkownika potrafi wyłączyć buforowanie całej strony, przez co sklep traci największą pojedynczą oszczędność, jaką ma.

Sposób pomiaru jest prosty i nie wymaga specjalistycznych narzędzi: wyłącz moduł na środowisku testowym, zmierz czas generowania strony i liczbę zapytań do bazy, włącz z powrotem. Różnica jest ceną tego modułu. Powtórzone dla wszystkich włączonych modułów daje ranking, który rozstrzyga, co zostaje, a co wychodzi. Szerzej o warstwie wydajności piszemy przy okazji optymalizacji wydajności PrestaShop.

Konflikty: gdy dwa moduły chcą tego samego

Najtrudniejsze do zdiagnozowania problemy nie biorą się z jednego złego modułu, tylko ze spotkania dwóch poprawnych. Trzy wzorce wracają najczęściej.

Dwa override'y tej samej metody. PrestaShop scala nadpisania w jeden plik, a przy kolizji drugi moduł nie może zainstalować swojego nadpisania. Instalacja przechodzi, funkcja nie działa, komunikat pojawia się w logu, którego nikt nie czyta.

Kolejność w hooku. Kilka modułów wpiętych w ten sam punkt wykonuje się w ustalonej kolejności, którą da się zmienić w panelu. Moduł modyfikujący cenę koszyka po module wyliczającym rabat da inny wynik niż przed nim. Kolejność bywa źródłem błędów w wyliczeniach, których nie da się odtworzyć bez znajomości tego mechanizmu.

Konkurencja o ten sam obszar strony. Dwa moduły wstawiające treść w to samo miejsce szablonu dają układ, w którym jeden przykrywa drugi albo oba wyświetlają się jeden pod drugim mimo że miał być tylko jeden.

Metoda diagnozy pozostaje ta sama od lat i nadal jest najszybsza: wyłącz połowę modułów, sprawdź, czy objaw zniknął, i połów dalej. Kilkanaście prób wystarcza, żeby zawęzić przyczynę do jednej pary, nawet w sklepie z kilkudziesięcioma modułami. Warunkiem jest środowisko testowe, bo na produkcji ta metoda oznacza wyłączanie płatności i dostaw w godzinach sprzedaży. Zapisuj przy tym kolejność prób, inaczej po dwudziestu minutach nie wiadomo, które kombinacje zostały już sprawdzone.

Środowisko testowe: warunek wstępny każdej pracy w tej warstwie

Brak kopii sklepu, na której da się bezpiecznie testować, jest najczęstszą przyczyną, dla której warstwa modułów zostaje nietknięta przez lata. Firma wie, że coś trzeba z nią zrobić, ale każda zmiana na produkcji oznacza ryzyko przerwania sprzedaży, więc decyzja jest odkładana.

Środowisko testowe użyteczne w tej pracy musi spełniać trzy warunki, a każdy z nich bywa pomijany:

• Ta sama wersja PHP i te same rozszerzenia co na produkcji. Różnica w wersji unieważnia większość testów, bo część problemów ujawnia się wyłącznie na konkretnej wersji.
• Kopia danych, nie przykładowy katalog. Konflikt między dwoma modułami ujawnia się przy realnej liczbie produktów i realnych kombinacjach, nie na dziesięciu przykładowych pozycjach.
• Odcięte integracje zewnętrzne. Środowisko testowe wysyłające realne zamówienia do systemu ERP albo maile do klientów jest gorsze niż jego brak. To odcięcie trzeba zrobić świadomie, przy każdym odświeżeniu kopii.

Do tego dochodzi sposób przenoszenia zmian z powrotem na produkcję. Kopiowanie plików ręcznie działa do pierwszego przeoczenia. Kontrola wersji kodu jest tu nie tyle dobrą praktyką, co warunkiem, żeby po trzech miesiącach dało się powiedzieć, co i kiedy zostało zmienione.

Porządkowanie na działającym sklepie

Warunkiem wstępnym jest środowisko testowe będące kopią produkcji, razem z danymi. Bez tego każda zmiana w tej warstwie jest zakładem, a nie decyzją. Dalej pracujesz partiami.

1. Moduły wyłączone i nieużywane. Zaczynasz od nich, bo ryzyko jest zerowe, a lista skraca się od razu o kilkanaście pozycji.
2. Moduły włączone, niewpięte w żaden aktywny hook. Sprawdzasz, czy nie są wywoływane z szablonu motywu, i wyłączasz.
3. Moduły dublujące funkcję. Dwa moduły do wysyłki newslettera albo trzy do wyświetlania opinii to typowy osad po zmianach wykonawcy. Zostaje jeden.
4. Override'y bez uzasadnienia. Każdy plik dostaje decyzję: przenieść do modułu z hookiem, zostawić z komentarzem wyjaśniającym, czy usunąć. Brak decyzji oznacza, że plik zostaje na kolejne trzy lata.
5. Modyfikacje w rdzeniu. Najtrudniejsza część. Każda zmiana przechodzi do modułu albo do override'a, a rdzeń wraca do wersji oryginalnej.
6. Aktualizacja pozostałych modułów. Dopiero teraz, gdy wiadomo, co zostaje i po co.

Po każdej partii przechodzisz pełną ścieżkę zakupową na środowisku testowym: wyszukanie produktu, dodanie do koszyka, checkout, płatność testowa, potwierdzenie i status zamówienia w panelu. Kwadrans na partię, a wyłapuje rzeczy, których nie widać w żadnym raporcie.

Osobno zaplanuj, jak wracasz z każdej partii, gdyby coś poszło nie tak. Kopia bazy i plików sprzed zmiany oraz zapisany moment, do którego wracasz, to warunek pracy w tej warstwie. Wdrożenia bez ścieżki powrotu kończą się tym, że zespół w piątek wieczorem odtwarza z pamięci, co zmienił od poniedziałku.

Kolejność partii dobierz według ryzyka, nie według wygody. Moduły wyłączone i nieużywane to praca bez ryzyka, którą można wykonać w dowolnym momencie. Zmiany w warstwie płatności i dostaw wykonuj poza szczytem sprzedaży, z zaplanowanym oknem na weryfikację, bo tam błąd oznacza wprost utracone zamówienia, a nie gorsze doświadczenie klienta.

Zasady, które utrzymują porządek

Sklep wraca do stanu sprzed porządków w rok, jeśli nie zmieni się sposób dokładania rzeczy. Cztery zasady, z których każda kosztuje kilka minut przy wdrożeniu, a oszczędza dni później.

• Nowy moduł wchodzi przez środowisko testowe, z pomiarem czasu generowania strony i liczby zapytań przed i po. Moduł, który nie zarabia na swój koszt, nie wchodzi.
• Każdy override ma komentarz z datą, powodem i wskazaniem, dlaczego nie dało się tego zrobić hookiem. Jedno zdanie, które oszczędza kolejnemu wykonawcy dzień pracy.
• Zero zmian w plikach rdzenia. Jeśli wyjątek jest konieczny, trafia do spisu odstępstw razem z uzasadnieniem.
• Przegląd raz na kwartał. Lista modułów z pytaniem, czy każdy jest nadal używany. Piętnaście minut.

W sklepach rozwijanych intensywnie ten nadzór zamyka się w stałej opiece technicznej, gdzie przegląd warstwy modułów jest częścią umowy, a nie osobnym zleceniem. Zakres takiej współpracy opisujemy przy okazji wsparcia technicznego PrestaShop.

Skąd brać moduły i czego wymagać przed instalacją

Większość długu w tej warstwie powstaje w momencie instalacji, a nie później. Moduł wybrany po cenie i po zrzutach ekranu bywa modułem, który za dwa lata nikt nie zaktualizuje, bo autor zniknął, a kod nie daje się przenieść na nowszą wersję PrestaShop.

Cztery pytania przed instalacją, z których każde da się zadać w minutę:

• Kiedy ukazała się ostatnia aktualizacja. Moduł bez aktualizacji od dwóch lat nie przejdzie kolejnej zmiany wersji sklepu.
• Które wersje PrestaShop deklaruje. Deklaracja obejmująca wersję, na którą planujesz przejść, jest warunkiem, a nie miłym dodatkiem.
• Czy instaluje override'y. To da się sprawdzić przed instalacją, przeglądając zawartość paczki. Moduł dokładający nadpisania do często modyfikowanych klas jest kandydatem na przyszły konflikt.
• Czy autor odpowiada na zgłoszenia. Historia odpowiedzi w miejscu, z którego bierzesz moduł, mówi więcej niż opis funkcji.

Osobno warto rozstrzygnąć, kiedy moduł gotowy, a kiedy własny. Funkcja standardowa w branży, obsługiwana przez wielu dostawców, zwykle nie zasługuje na własny kod. Logika specyficzna dla Twojego modelu sprzedaży, której moduł gotowy nie obsługuje bez sześciu obejść, jest tańsza jako własny moduł niż jako łańcuch konfiguracji cudzego. Granicę wyznacza liczba obejść, nie cena licencji.

Co to daje w liczbach, których nie ma w analityce

Efektem uporządkowanej warstwy modułów nie jest wzrost konwersji, tylko zmiana charakteru każdego kolejnego zlecenia. Zmiana w checkoucie przestaje wymagać testowania całego sklepu, bo wiadomo, co jeszcze dotyka tego obszaru. Aktualizacja wersji PrestaShop staje się operacją planowaną, a nie odkładaną. Nowy wykonawca wchodzi w projekt w dni, a nie w tygodnie.

Jest jeszcze jeden efekt, trudniejszy do wyceny, a odczuwalny od pierwszego tygodnia. Zespół przestaje omijać sklep. Tam, gdzie każda zmiana wiąże się z ryzykiem, firmy zaczynają realizować pomysły poza platformą: osobną stroną kampanijną, arkuszem, ręcznym procesem obok systemu. Uporządkowana warstwa techniczna sprawia, że pomysł handlowy wraca do sklepu, bo wdrożenie go tam przestaje być droższe niż obejście.

Jeden praktyczny sprawdzian, który mówi, gdzie jesteś: ile trwa u Ciebie dołożenie pola do formularza zamówienia i ilu obszarów sklepu trzeba przy tym dotknąć. Odpowiedź na to pytanie jest dokładniejszą miarą stanu warstwy technicznej niż jakikolwiek automatyczny raport. Miejsce tego obszaru wśród pozostałych porządkuje przewodnik o optymalizacji PrestaShop.