Karta oceny ryzyka modułu: 12 kontroli przed instalacją na sklepie

Nie musi Pan umieć czytać PHP, żeby ocenić, czy moduł PrestaShop można bezpiecznie umieścić na działającym sklepie. Większość szkód, jakie wyrządza zły moduł, widać z przeglądarki i z back office — jeśli wie Pan, gdzie patrzeć. Oto lista kontrolna, której używamy, spisana tak, by właściciel sklepu mógł ją przejść bez programisty.

Zasada jest prosta. Moduł to kod bez izolacji, który działa z pełnymi uprawnieniami sklepu: może ładować zasoby na każdej stronie, zapisywać dane do bazy, zmieniać podstawowe zachowanie i łączyć się z innymi serwerami. Zamiast więc ufać stronie sprzedażowej, obserwuje Pan, co moduł faktycznie robi na bezpiecznej kopii sklepu, i przyznaje mu ocenę. Dziesięć zielonych znaczników na dwanaście to moduł, który można instalować ze spokojem. Ale sama ocena nie mówi wszystkiego: niektóre wiersze są bezwzględne. Czerwona flaga przy checkoucie lub danych klientów, przy teście odwracalności, przy nowej zewnętrznej domenie albo przy nieujawnionych nadpisaniach (override) oznacza, że moduł nie trafia na działający sklep, dopóki producent tego nie wyjaśni — niezależnie od tego, co pokazują pozostałe wiersze.

Najpierw przeprowadź to na kopii testowej (staging) — nigdy na wersji produkcyjnej. Proszę zduplikować sklep (większość firm hostingowych oferuje klon staging jednym kliknięciem) albo użyć jednorazowej instalacji z Pana motywem i pozostałymi modułami. Chodzi o to, aby moduł zmierzył się z tą samą złożoną rzeczywistością, w której działa Pana prawdziwy sklep: Pana motyw, Pana konfiguracja języka i waluty, Pana istniejące moduły, Pana wersje PrestaShop i PHP. Moduł, który zachowuje się poprawnie wyłącznie na czystej instalacji, coś Panu tym sygnalizuje.

Dwanaście testów

1. Zewnętrzne domeny i sieci CDN

Jak to sprawdzić: proszę otworzyć w przeglądarce stronę główną sklepu — nie stronę ustawień modułu — nacisnąć F12, aby uruchomić Narzędzia deweloperskie, kliknąć zakładkę Network (Sieć) i przeładować stronę. Proszę posortować według domeny. Proszę zanotować każdą domenę, która nie należy do Pana. Teraz proszę zainstalować moduł i przeładować stronę ponownie. Czy pojawiła się jakaś nowa domena zewnętrzna?

Zaliczenie: brak nowych domen zewnętrznych na stronach, które nie korzystają z danej funkcji. Tryb awarii: to dokładnie ta pułapka z naszego eseju — moduł ładujący czcionkę, skrypt lub tracker z cudzego serwera na każdej stronie, dokładający zapytania DNS, wagę, ekspozycję prywatności i zależność od serwera, nad którym nie ma Pan kontroli. Jeśli któregoś dnia ten serwer będzie wolny albo niedostępny, renderowanie Pana witryny może się zaciąć lub pogorszyć razem z nim.

Jeśli woli Pan policzyć je dokładnie, zamiast przeglądać listę wzrokiem, proszę wkleić to do tej samej zakładki Console (Konsola) w Narzędziach deweloperskich i nacisnąć Enter — wypisze każdą domenę, która nie należy do Pana, oraz liczbę żądań wykonanych do każdej z nich:

// On your homepage: reload the page first, then paste this into DevTools → Console.
const here = location.host;
const thirdParty = {};
for (const r of performance.getEntriesByType('resource')) {
    const host = new URL(r.name).host;
    if (host && host !== here) {
        thirdParty[host] = (thirdParty[host] || 0) + 1;
    }
}
console.table(thirdParty); // each row is an external host your page called

Liczy każdy host, który nie jest Pana główną domeną — w tym wszelkie subdomeny CDN prowadzone przez Pana samego, które można spokojnie zignorować. Proszę uruchomić to przed zainstalowaniem modułu, a potem jeszcze raz po instalacji: każdy naprawdę nowy host to nowa strona trzecia, od której zależy teraz Pana witryna.

To najcenniejszy test na całej liście, ponieważ wychwytuje dokładnie tę awarię z naszego eseju: moduł, który po cichu dokłada zewnętrzną domenę do każdej strony. Jeśli pojawi się tu host, którego nie dodał Pan świadomie, proszę się zatrzymać i zapytać producenta dlaczego, zanim moduł kiedykolwiek trafi na działający sklep.

2. Globalne zasoby front-office

Jak to sprawdzić: w tej samej zakładce Network proszę odfiltrować CSS i JS i porównać liczbę plików na stronie głównej przed instalacją i po niej. Następnie proszę sprawdzić stronę, na którą moduł powinien mieć wpływ, oraz stronę, na którą wpływać nie powinien.

Zaliczenie: arkusze stylów i skrypty modułu ładują się wyłącznie na stronach, które z nich korzystają. Tryb awarii: „mały” moduł, który rejestruje swoje zasoby na globalnym hooku nagłówka, dokłada wagę do każdej strony w sklepie, łącznie z checkoutem, dla funkcji żyjącej w jednym tylko miejscu. Proszę pomnożyć to przez kilkanaście niedbałych modułów, a otrzyma Pan wolny sklep bez jednego winowajcy.

3. Nadpisania (override)

Jak to sprawdzić: przed instalacją proszę zajrzeć do folderu /override sklepu przez FTP lub menedżera plików u dostawcy hostingu (sprawdza Pan tylko, czy pojawiają się pliki — nie trzeba ich czytać). Proszę zainstalować moduł, a potem zajrzeć ponownie.

Zaliczenie: w /override nie pojawiły się żadne nowe pliki (standardowy folder zawiera już zastępcze pliki index.php — szuka Pan nowych). Tryb awarii: nadpisania żyją w /override i zmieniają zachowanie podstawowych klas oraz kontrolerów PrestaShop. Dwa moduły nadpisujące tę samą klasę wchodzą w konflikt, a — co kluczowe — nadpisanie pozostawione po odinstalowaniu jest jedną z głównych przyczyn sytuacji „sklep się zepsuł, a wyłączanie modułów tego nie naprawiło”. Dobre moduły używają hooków i usług, zamiast nadpisywać rdzeń.

4. Wykorzystane hooki

Jak to sprawdzić: w back office proszę przejść do Wygląd › Pozycje (ekran hooków) i zobaczyć, gdzie moduł się zarejestrował. Zwykle hooki modułu widać też na jego stronie konfiguracji.

Zaliczenie: hooki pasują do funkcji. Moduł wysyłki podpina się pod wysyłkę i checkout; moduł zakładki produktu podpina się pod stronę produktu. Tryb awarii: moduł podpięty pod każdą stronę — displayHeader, displayFooter wszędzie — „na wszelki wypadek”, podczas gdy jego funkcja pojawia się tylko w jednym miejscu. Każdy z tych hooków to kod uruchamiany przy każdym wczytaniu strony.

5. Zmiany w schemacie bazy danych

Jak to sprawdzić: w narzędziu bazodanowym u dostawcy hostingu (phpMyAdmin lub podobne) proszę zanotować liczbę tabel przed instalacją. Proszę zainstalować i zobaczyć, co zostało dodane — sprawdza Pan nazwy, nie zawartość.

Zaliczenie: nowe tabele mają wyraźną przestrzeń nazw przypisaną do modułu (rozpoznawalny prefiks) i, najlepiej, są udokumentowane. Kilka dobrze nazwanych tabel jest całkowicie normalne i w porządku. Tryb awarii: moduł, który rozsiewa nieopisane tabele albo zapisuje do podstawowych tabel PrestaShop w sposób, którego nie ujawnia, to moduł, o którym nie da się później spokojnie rozumować.

Jeśli ma Pan dostęp do bazy danych (phpMyAdmin lub wiersz poleceń), może Pan wypisać dokładnie to, co moduł dodał. Proszę zanotować listę przed instalacją, a potem uruchomić zapytanie ponownie po niej i porównać:

-- Note the list before installing, then run it again afterwards and compare.
SHOW TABLES;

-- Most well-built modules prefix their own tables — list them (base table + children):
SHOW TABLES LIKE 'ps\_mymodule%';

Krótka, wyraźnie oprefiksowana lista jest zdrowa. To, na co Pan uważa, to rozsiane nieopisane tabele — albo nieujawnione zapisy do podstawowych tabel, takich jak ps_orders czy ps_customer. (ps_ to domyślny prefiks tabel; proszę podstawić własny, jeśli został zmieniony, i użyć technicznej nazwy modułu w miejsce mymodule.)

6. Porządkowanie po odinstalowaniu

Jak to sprawdzić: po sprawdzeniu schematu proszę odinstalować moduł i zajrzeć do bazy danych ponownie. Co usunął, a co zostawił?

Zaliczenie: moduł usuwa to, co utworzył — albo jasno stwierdza w dokumentacji, co świadomie zachowuje i dlaczego (zachowanie ustawień na potrzeby przyszłej ponownej instalacji to uzasadniony wybór, o ile jest ujawniony). Tryb awarii: ciche pozostałości. Osierocone tabele, wiersze konfiguracji i nieaktualne pliki, które gromadzą się za każdym razem, gdy testuje Pan moduł. To ten wiersz, w którym „po prostu go odinstaluję” po cichu zawodzi.

7. Zadania cron i webhooki

Jak to sprawdzić: proszę sprawdzić dokumentację i stronę konfiguracji modułu pod kątem wszystkiego, co uruchamia się według harmonogramu lub w tle łączy się z usługą zewnętrzną — synchronizacje, feedy, zadania czyszczące, integracje typu „połącz swoje konto”.

Zaliczenie: zadania działające w tle są ujawnione i można je wyłączyć. Tryb awarii: nieujawniona aktywność w tle — zadanie obciążające Pana bazę danych według harmonogramu albo webhook wysyłający Pana dane gdzieś, gdzie nie zdawał sobie Pan sprawy. Nie da się zarządzać czymś, o czym nie wie Pan, że działa.

8. Punkty styku z checkoutem, zamówieniami i danymi klientów

Jak to sprawdzić: z modułem zainstalowanym na staging proszę złożyć pełne zamówienie testowe od początku do końca. Proszę wyszukać produkt. Proszę otworzyć stronę produktu. Proszę otworzyć główne ekrany back office. Czy wszystko nadal działa dokładnie tak jak wcześniej?

Zaliczenie: checkout, wyszukiwanie, strony produktów i panel administracyjny pozostają nienaruszone, chyba że to dosłownie zadanie modułu. Tryb awarii: moduł, który dotyka procesu zamówienia lub rekordów klientów, dotyka Pana przychodu i Pana obowiązków zgodności (RODO). Checkout, który się psuje — albo po cichu źle liczy — kosztuje Pana prawdziwe pieniądze w dniu wdrożenia, a nie w laboratorium.

9. Multishop, język i waluta

Jak to sprawdzić: jeśli prowadzi Pan więcej niż jeden sklep, więcej niż jeden język lub więcej niż jedną walutę, proszę przetestować moduł w każdym z tych wariantów. Proszę przełączyć sklep, przełączyć język, przełączyć walutę i skorzystać z funkcji.

Zaliczenie: moduł respektuje Pana konfigurację — poprawnie dla każdego sklepu, przetłumaczony dla każdego języka, z właściwymi kwotami dla każdej waluty. Tryb awarii: moduł zbudowany i przetestowany pod kątem „sklep 1, angielski, euro”, który zaszywa te założenia na sztywno. W demie wygląda dobrze, a rozpada się na Pana drugiej witrynie albo na cenach Pana polskich klientów.

10. Zgodność z PrestaShop i PHP

Jak to sprawdzić: proszę przeczytać deklarację zgodności na stronie produktu i zestawić ją z Pana wersją PrestaShop (1.7, 8.x lub 9.x) oraz Pana wersją PHP.

Zaliczenie: producent podaje dokładne wersje, które moduł wspiera, i utrzymuje to na bieżąco w miarę wydawania nowych wersji PrestaShop. Tryb awarii: „zgodny ze wszystkimi wersjami”. Żaden poważny moduł nie jest testowany pod kątem każdej wydanej kiedykolwiek wersji PrestaShop i PHP; ta deklaracja to marketing i jest to wiersz, który najprawdopodobniej pęknie w dniu, w którym zaktualizuje Pan sklep.

11. Historia zmian i ślad wsparcia

Jak to sprawdzić: zanim Pan kupi, proszę poszukać datowanej historii zmian (changelog) i prawdziwego kanału wsparcia.

Zaliczenie: moduł ma widoczną historię aktualizacji oraz sposób dotarcia do człowieka, który go utrzymuje. Tryb awarii: brak historii zmian i brak wsparcia oznacza brak właściciela. Moduł bez utrzymania to moduł, który prędzej czy później przestanie działać przy aktualizacji PrestaShop lub PHP, a nikt go nie naprawi — i dowie się Pan o tym w najgorszym możliwym momencie.

12. Test odwracalności

Jak to sprawdzić: to cała lista kontrolna w jednym ruchu, na staging. Proszę zrobić migawkę sklepu. Zainstalować moduł. Wyłączyć go. Odinstalować. Porównać sklep z migawką.

Zaliczenie: instalacja → wyłączenie → odinstalowanie pozostawia sklep zasadniczo w takim stanie, w jakim był — bez pozostawionych plików, bez osieroconych tabel, bez zepsutych stron. Tryb awarii: cokolwiek, co nie wraca do poprzedniego stanu. Jeśli modułu nie da się czysto usunąć na kopii testowej, z pewnością nie da się go czysto usunąć z działającego sklepu pod presją.

Czerwone flagi i co każda z nich naprawdę oznacza

Nie zawsze znajdzie Pan czas na pełną dwunastkę. Oto skróty — sygnały, które same w sobie uzasadniają znacznie dokładniejsze przyjrzenie się. Każdy odwzorowuje konkretny sposób, w jaki sprawy idą źle:

Żaden z tych sygnałów nie jest dowodem, że moduł jest zły. Tani i prosty kod potrafi być całkiem dobry; mały producent może być znakomity. Problemem nigdy nie jest cena ani autor — jest nim niezarządzane ryzyko. Czerwona flaga oznacza tylko tyle, że ryzyko nie zostało zarządzone za Pana, więc musi Pan zarządzić nim sam, zanim moduł trafi na działający sklep.

Gdzie w to wszystko wpisują się oficjalne standardy

Samo PrestaShop publikuje reguły techniczne, których dobrze zbudowany moduł powinien przestrzegać. Nie musi ich Pan wdrażać, ale przydają się jako punkt odniesienia, na który można skierować producenta, i pokrywają się z dużą częścią powyższego. PrestaShop publikuje Techniczne standardy tworzenia oprogramowania, których dobrze zbudowany moduł powinien przestrzegać — dyscyplina nadpisań, higiena podstawowych tabel i wydajności zasobów, bezpieczeństwo oraz zgodność wersji — obok Standardów jakości stojących za odznaką Verified+ na rynku Addons. Żaden z nich nie jest gwarancją sam w sobie — wiele dobrych modułów żyje poza tym rynkiem, a odznaka nie zastąpi obserwacji opisanych powyżej — ale są rozsądnym elementem całego obrazu. Jeśli kupuje Pan przez rynek Addons, nasz przewodnik kupującego po PrestaShop Addons podpowiada, jak czytać ofertę.

Bezpieczna kolejność instalacji, od początku do końca

Zebrane w całość, wszystko to jest jedną spokojną sekwencją:

• Kopia zapasowa działającego sklepu — pliki i baza danych.
• Instalacja na kopii testowej (staging), która odwzorowuje Pana prawdziwy motyw, moduły i ustawienia.
• Migawka sklepu testowego, a następnie przejście przez dwanaście testów powyżej.
• Obserwacja zakładki Network na stronie głównej pod kątem nowych domen i zasobów ładowanych w całej witrynie.
• Złożenie zamówienia testowego i sprawdzenie wyszukiwania, stron produktów oraz panelu administracyjnego.
• Odinstalowanie i porównanie z migawką — potwierdzenie, że wszystko wraca czysto.
• Dopiero wtedy instalacja na wersji produkcyjnej, w spokojnym oknie czasowym, i ponowne sprawdzenie kluczowych stron.

Częste pytania

Czy potrzebuję programisty, żeby zweryfikować moduł?

Przy większości tych testów — nie. Liczenie żądań stron trzecich, testowanie checkoutu oraz przeprowadzenie testu instalacja → wyłączenie → odinstalowanie to rzeczy, które może Pan wykonać z przeglądarki i back office na kopii testowej. Kilka testów — zajrzenie do /override, wypisanie tabel bazy danych — wymaga dostępu do plików lub bazy, który może przekazać Panu dostawca hostingu albo programista, ale nigdy nie musi Pan czytać żadnego kodu.

Jeśli moduł jest na oficjalnym rynku PrestaShop, czy jest automatycznie bezpieczny?

Weryfikacja rynku i odznaka Verified+ to prawdziwy, użyteczny sygnał — sprawdzają za Pana wiele z tych rzeczy. Ale nie zastąpią obserwowania, jak moduł zachowuje się na Pana własnym sklepie, z Pana motywem i Pana pozostałymi modułami. Wiele dobrych modułów żyje także poza rynkiem. Proszę przeprowadzić testy tak czy inaczej.

Moduł jest darmowy — czy to samo w sobie jest czerwoną flagą?

Nie. Darmowe i tanie moduły potrafią być znakomite, a drogie potrafią być niedbałe. Cena nie mówi nic o tym, jak zachowuje się kod. Karta oceny dotyczy zarządzanego ryzyka, a nie kosztu: darmowy moduł, który przechodzi te testy, jest bezpieczniejszy niż płatny, który je oblewa.

Jeśli mam czas tylko na jeden test, który to?

Proszę otworzyć zakładkę Network na stronie głównej i policzyć nowe domeny stron trzecich po instalacji. Zajmuje to minutę, nie wymaga kodu i wychwytuje najczęstszy oraz najbardziej szkodliwy rodzaj niedbałego modułu — ten, który obciąża każdą stronę dla funkcji, którą będzie Pan widywać rzadko.

Rozpisane brzmi to jak sporo pracy; w praktyce to jedno popołudnie i jest o wiele tańsze niż popołudnie, które spędziłby Pan w przeciwnym razie na dochodzeniu, dlaczego witryna zwolniła albo dlaczego jakaś strona nie wraca po usunięciu modułu, który ją zepsuł. Aby poznać historię stojącą za tym, dlaczego to ma znaczenie — oraz uczciwą relację z błędu, który sami popełniliśmy — proszę przeczytać co moduł PrestaShop może zrobić, czego odinstalowanie nie cofnie. I tak: proszę przeprowadzić tę listę kontrolną również wobec naszych modułów. Po to właśnie jest. Jeśli woli Pan, żebyśmy przeprowadzili ją za Pana, nasz bezpłatny skan bezpieczeństwa i audyt wydajności są zbudowane dokładnie na tych testach — a jeśli woli Pan, aby sklep pilnował tych rzeczy nieprzerwanie, a nie tylko w momencie instalacji, to jest właśnie zadanie modułów Performance Revolution i Security Revolution.