Najszybszy sposób rozbudowy sklepu to poprawienie pliku platformy. Jest też najdroższy — koszt przychodzi przy pierwszej aktualizacji.
Co się dzieje po zmianie rdzenia
Aktualizacja nadpisuje plik i zmiana znika. Albo aktualizacja nie przechodzi, bo plik jest inny niż oczekiwany. W obu przypadkach sklep zostaje na starej wersji, a wraz z nią na starych błędach bezpieczeństwa.
Gorsze jest to, co dzieje się dalej. Skoro aktualizacja nie przechodzi, kolejne też się odkładają. Po roku sklep dzieli od bieżącej wersji kilka wydań, a skok przez wszystkie naraz jest już osobnym projektem, a nie czynnością serwisową.
Mechanizmy przewidziane przez platformę
- wtyczki i moduły reagujące na zdarzenia,
- nadpisania szablonu w katalogu motywu,
- punkty rozszerzeń w kodzie platformy,
- zewnętrzne usługi wywoływane przez interfejs programistyczny.
Każdy z nich przeżywa aktualizację. Zmiana w rdzeniu — nie.
Wybór między nimi zależy od tego, co ma się zmienić. Sam wygląd to warstwa szablonu. Reakcja na zdarzenie — na przykład dopisanie czegoś w chwili złożenia zamówienia — to wtyczka. Logika, która ma żyć własnym życiem i być używana także poza sklepem, lepiej nadaje się na osobną usługę wywoływaną przez interfejs programistyczny.
Nadpisania szablonu
Zmiany wyglądu należą do motywu, nie do plików platformy. Motyw potomny izoluje je od aktualizacji zarówno platformy, jak i samego motywu.
Nadpisanie ma jednak swoją cenę: kopiuje plik w wersji, którą widzisz dziś. Gdy autor motywu poprawi oryginał, twoja kopia zostanie ze starą treścią i nie dowiesz się o tym sama z siebie. Dlatego nadpisań powinno być tyle, ile trzeba, i każde powinno być odnotowane.
Gdy naprawdę nie ma punktu zaczepienia
Zdarza się. Wtedy właściwą drogą jest zgłoszenie do autora platformy albo utrzymywanie zmiany jako opisanej łaty nakładanej świadomie po każdej aktualizacji — nie cicha poprawka, o której nikt nie pamięta.
Łata powinna leżeć w osobnym pliku, obok krótkiej notatki: co zmienia, dlaczego i jak sprawdzić, że nadal działa. To minimum, które pozwala kolejnej osobie zrozumieć sytuację bez czytania całego kodu.
Ewidencja zmian
Spis tego, co i gdzie zmieniono, jest warunkiem bezpiecznej aktualizacji. Bez niego każda aktualizacja jest skokiem w ciemno. Spis prowadzi się razem z listą rozszerzeń i wersji — temat wraca w tekście o aktualizacjach i zgodności wersji.
Kiedy zmiana rdzenia bywa dopuszczalna
Przy sklepie, który i tak idzie do wymiany, oraz przy poprawce ratującej sprzedaż tu i teraz, z terminem usunięcia. W obu przypadkach to decyzja świadoma i zapisana, a nie sposób pracy. Jeśli takich poprawek uzbierało się kilka, punktem wyjścia nie jest kolejna łata, tylko przegląd tego, czego sklep naprawdę potrzebuje, i przeniesienie zmian na mechanizmy przewidziane przez platformę.
