Jak wybierać, instalować i testować moduły PrestaShop

Co byśmy zrobili

Określilibyśmy brakujący efekt biznesowy, sprawdzili ustawienia natywne i posiadane już moduły, a nowy moduł porównali tylko wtedy, gdy luka pozostaje. Wybór zależy od istniejącego sklepu: jego konfiguracji, wersji modułów, integracji, modyfikacji motywu, danych katalogu i klientów, rynków oraz zespołu utrzymującego sklep. Zastąpienie działającego narzędzia wymaga korzyści, którą można wykazać w tym sklepie.

Wprowadź wybraną zmianę na zabezpieczonej kopii testowej odzwierciedlającej produkcję, przećwicz konfigurację i wycofanie, a następnie zaplanuj przełączenie. Uzgodnij, kto może zatrzymać wdrożenie, jakie dowody pozwalają na ponowne otwarcie i jak uzgodnisz zamówienia lub komunikaty integracji, jeśli potrzebne będzie odtwarzanie. Nie kopiuj starej bazy testowej na sklep prowadzący sprzedaż, aby opublikować ustawienie modułu.

Jeśli potrzebujesz porównania kandydatów i wdrożenia, PrestaShop Module Selection & Fit Assessment sprawdza dostępne drogi na kontrolowanej kopii sklepu; dla już wybranego modułu PrestaShop Module Installation & Configuration Service instaluje go, konfiguruje uzgodnione ustawienia i weryfikuje daną ścieżkę.

Zapisz wymaganie, które da się przyjąć lub odrzucić

Przekaż każdemu kandydatowi ten sam brief. Opisz zadanie, które dziś zawodzi, jego wykonawcę i wynik uzasadniający zmianę. Oddziel niezbędne działanie od opcjonalnej prezentacji, aby długa lista funkcji nie ukryła brakującego wymagania.

• Kontekst sklepu: dokładne wersje rdzenia, PHP serwera WWW i motywu, istotne moduły i modyfikacje, języki, waluty, sklepy oraz grupy klientów.
• Granice danych i integracji: odpowiednie pola katalogu, rekordy klientów lub statusy zamówień, dalsze miejsca przeznaczenia tych rekordów i system odpowiedzialny za każdą wartość.
• Dowody odbioru: reprezentatywny produkt lub koszyk, kroki odtworzenia, oczekiwane wyniki dla klienta i pracowników oraz porównanie z obecnym sklepem.
• Ograniczenia operacyjne: kto konfiguruje funkcję, jakiego dostępu potrzebuje, jak monitorowana jest praca w tle i kto utrzymuje rozwiązanie po przekazaniu.
• Warunki zakończenia korzystania: ustawienia i rekordy do wyeksportowania lub zachowania, oczekiwane działanie wyłączenia i odinstalowania oraz sposób odzyskania działania po nieudanej zmianie.

Na przykład „poprawić dostawę” to zbyt ogólne wymaganie do testowania. „Oferować tylko dostępnych przewoźników i przeliczać sumę dostawy z podatkiem, gdy powracający klient zmienia adres, a następnie eksportować wybraną usługę do naszego systemu zamówień” daje dostawcy konkretną ścieżkę do pokazania. Zrzut selektora przewoźników odpowiada tylko na część briefu.

Sprawdź zgodność z konkretnymi wersjami PrestaShop i PHP

Zapisz pełną wersję PrestaShop, wersję PHP używaną przez serwer WWW, wersję motywu i zainstalowane moduły w Zaawansowane > Informacje oraz Menedżerze modułów. Stwierdzenie „obsługuje 1.7” jest mniej przydatne niż konkretne wydanie i przetestowana kombinacja z PHP.

Deklaracja zgodności z rdzeniem to $this->ps_versions_compliancy w głównej klasie PHP modułu. Na przykład ta deklaracja używa uruchomionej wersji sklepu jako górnej granicy:

$this->ps_versions_compliancy = [
    'min' => '1.6.1.0',
    'max' => _PS_VERSION_,
];

Deklarowany zakres to ograniczenie instalacji, a nie raport z testów. PHP modułu działa z uprawnieniami sklepu i może uzyskać dostęp do jego bazy, danych klientów i zapisywalnych plików, więc same kontrole w przeglądarce nie dowodzą bezpieczeństwa kodu. Osobno przeczytaj wymagania PHP i bibliotek w Composer. Środowisko PHP musi jednocześnie spełniać wymagania rdzenia, modułu i zależności. Nowa składnia może wywołać błąd, zanim moduł wyświetli pomocny komunikat. Nie obniżaj wymagania w kodzie, aby obejść kontrolę.

Przypisz każde środowisko testowe do dokładnego wydania rdzenia i PHP. W testach historycznych PrestaShop 1.7.6 obsługuje PHP tylko do 7.2, 1.7.8 do 7.4, a PrestaShop od 8.0 do 8.2 obsługuje PHP do wersji 8.1. Te stare kombinacje są informacją o zgodności, a nie aktualnym zaleceniem hostingowym.

Wymagania PrestaShop 9 rozróżniają 9.0, obsługujące PHP od 8.1 do 8.4, oraz 9.1, obsługujące PHP od 8.1 do 8.5. Przed wyborem środowiska sprawdź wymagania konkretnego wydania docelowego, także 9.2. Uruchamiaj odpowiednie testy na 9.2 i na każdym starszym wydaniu, które wspierasz.

Sprawdź override/, skrypty instalacji i aktualizacji, definicje usług oraz pliki kopiowane poza moduł. Pusty katalog nadpisań mówi jedynie, że brak konwencjonalnych nadpisań. Wyszukaj też rejestracje hooków i porównaj je z faktycznie zainstalowanymi w każdym sklepie.

Przygotuj środowisko testowe i kopię umożliwiającą odtworzenie

Kopia testowa powinna odpowiadać produkcji pod względem rdzenia, PHP i rozszerzeń, silnika bazy danych, motywu, modułów, ustawień sklepu i konfiguracji serwera. Porównaj kontekst multistore, języki, waluty, pamięć podręczną i łączność wychodzącą. Czyste demo pomaga zobaczyć funkcję, ale nie odtwarza interakcji w Twoim sklepie.

Chroń kopię przed publicznym dostępem i indeksowaniem. Usuń lub zanonimizuj dane klientów tam, gdzie to praktyczne. Wyłącz rzeczywiste pobieranie płatności, e-maile do klientów, produkcyjne webhooki i integracje cykliczne. Używaj danych uwierzytelniających sandboxa płatności i kontrolowanej skrzynki pocztowej.

1. Wykonaj wspólną kopię kompletnych plików sklepu i bazy danych, w tym nadpisań, modyfikacji motywu i konfiguracji.
2. Zachowaj dokładny bieżący ZIP modułu, wersję i eksport konfiguracji, jeśli jest dostępny.
3. Przechowuj kopie poza publicznym katalogiem WWW i potwierdź możliwość ich odtworzenia.
4. Zapisz stan odniesienia stron i procesów, które będziesz testować.

Dla bazy InnoDB programista może wykonać spójny zrzut logiczny, taki jak poniższy, z prywatnego katalogu kopii. Zastąp bazę i konto rzeczywistymi wartościami. Osobno skoordynuj zapisy i ewentualne tabele nietransakcyjne.

mysqldump --single-transaction -u backupuser -p prestashop > before-module.sql

Szersze przygotowanie opisują poradnik środowiska testowego i poradnik kopii zapasowych.

Zainstaluj ZIP i zdiagnozuj błędy przesyłania

W PrestaShop 8 i 9 otwórz Moduły > Menedżer modułów > Załaduj moduł i prześlij dostarczony instalacyjny ZIP. Zachowaj techniczną nazwę katalogu. Na przykład mprcanonicalmanager/mprcanonicalmanager.php należy umieścić pod modules/mprcanonicalmanager/, z zależnościami i pozostałymi katalogami obok pliku głównego.

Archiwum pobrane z repozytorium może mieć dodatkowy katalog nadrzędny lub nie zawierać zbudowanych zależności. Używaj pakietu wydania przeznaczonego do instalacji. Samo kopiowanie plików nie uruchamia install(), które może tworzyć tabele, rejestrować hooki, dodawać ekrany administracyjne i inicjować wartości domyślne.

Jeśli przesyłanie w przeglądarce nie działa, porównaj rozmiar archiwum z rzeczywistymi wartościami upload_max_filesize i post_max_size PHP serwera WWW. Druga musi pomieścić też resztę żądania POST. Informacje pokazują niektóre wartości PHP. post_max_size odczytaj z ustawień PHP hostingu lub prywatnej diagnostyki środowiska WWW. CLI php -i może czytać inną konfigurację.

; Example limits for a ZIP smaller than 64 MB
upload_max_filesize = 64M
post_max_size = 80M
max_execution_time = 300

To przykłady, a nie minimalne wymagania każdego modułu. Sprawdź też limity rozmiaru żądań proxy i serwera WWW, miejsce tymczasowe i na rozpakowanie, wymagane rozszerzenia oraz uprawnienia zapisu. Dyrektyw php_value w .htaccess używaj tylko tam, gdzie wspiera je integracja PHP z Apache. Nie są ogólnym rozwiązaniem dla PHP-FPM.

W razie potrzeby rozpakuj ZIP lokalnie i prześlij jego pojedynczy techniczny katalog modułu przez SFTP. Następnie zainstaluj go w Menedżerze modułów. Potwierdź właściciela i dostęp faktycznego użytkownika PHP, zamiast nadawać zapis wszystkim.

Podczas instalacji obserwuj var/logs/ oraz logi PHP-FPM i serwera WWW. Zaawansowane > Logi to inne możliwe źródło, ale wczesne błędy mogą nigdy tam nie trafić. Moduł widoczny na dysku nadal mógł ulec awarii podczas tworzenia tabel, rejestracji hooków, ładowania zależności lub innego etapu instalatora. Zachowaj błąd i sprawdź stan częściowy przed ponowieniem. Nie usuwaj w ciemno tabel modułu ani ról autoryzacji.

Po powodzeniu otwórz Konfiguruj, podaj wymagane ustawienia sprzedawcy, zapisz i odśwież. Sprawdź uprawnienia, tłumaczenia, pozycje menu i zamierzony kontekst sklepu.

Przeprowadź testy funkcjonalne i regresyjne

Przekształć udokumentowaną listę funkcji i brief wymagań w listę kontrolną z oczekiwanymi wynikami. Testuj trwałość konfiguracji, uprawnienia i wszystkie objęte zmianą typy stron. Użyj tych samych danych przed instalacją i po niej. Zachowaj razem ZIP modułu, konfigurację, kroki testu, wyniki oczekiwane i rzeczywiste oraz zanonimizowane dowody, aby dostawca mógł odtworzyć błąd.

1. Dodaj produkt do koszyka ze strony produktu, kategorii i wyników wyszukiwania. Te miejsca wejścia mogą mieć różne znaczniki i JavaScript, nawet gdy zmiana koszyka trafia do tego samego CartController.
2. Zakończ zakup w trybie sandbox. Potwierdź produkty, kombinacje, adresy, opcje dostawy, podatki, rabaty, walutę i sumy zarówno w zamówieniu, jak i w systemie płatności.
3. Zarejestruj klienta, sprawdź oczekiwany e-mail, wyloguj się i zaloguj ponownie. Sprawdź historię konta.
4. Przetestuj wyszukiwania obsługiwane przez sklep, w tym nazwy produktów, indeksy i EAN tam, gdzie są indeksowane.
5. Otwórz szczegóły zamówienia w administracji. Sprawdź informacje przewoźnika, zakładki, notatki i odpowiednie uprawnienia pracowników.
6. Opróżnij koszyk i powtórz kluczowe interakcje na urządzeniu mobilnym, także przy wąskim widoku, na przykład 375 pikseli.
7. Przełącz każdy istotny język, walutę i sklep. Potwierdź, że ustawienia i treści pozostają we właściwym zakresie.

W narzędziach programistycznych przeglądarki sprawdź błędy konsoli, nieudane żądania AJAX, odpowiedzi 404 zasobów i nieoczekiwane hosty zewnętrzne. Odwiedź strony, na których funkcja się pojawia, i te, na których nie powinna nic robić. Sprawdź kopie szablonów modułów w motywie pod themes/your-theme/modules/, gdy zaktualizowana funkcja nie jest widoczna.

Osobno sprawdź zadania cykliczne i webhooki. Potwierdź uwierzytelnianie, częstotliwość, cel i obsługę błędów. Pomyślne załadowanie strony nie dowodzi prawidłowego działania zadań w tle.

Sprawdź moduł, który działa w demo, ale zawodzi w Twoim sklepie

Załóżmy, że testujesz blok rekomendacji produktów w wielojęzycznym sklepie z kombinacjami i eksportem zamówień. Demo dowodzi, że rekomendacje się wyświetlają. Test odbiorczy musi też potwierdzić, że kupujący nadal kupują właściwy artykuł, a pracownicy otrzymują poprawne zamówienie.

Jeśli dodawanie do koszyka z kategorii działało przed instalacją, a teraz zawodzi, zachowaj to porównanie i zatrzymaj wdrożenie. Wyodrębnij konflikt przy użyciu poniższych kontroli, a po poprawce powtórz test na tych samych danych. Poprawne wyświetlanie rekomendacji nie rekompensuje zepsutej ścieżki zakupu.

Zmierz zasoby, zapytania i zależności zewnętrzne

Porównuj powtarzane ładowania stron w tych samych warunkach. Oddziel wyniki zimnej i rozgrzanej pamięci podręcznej. Zapisuj czas odpowiedzi serwera, liczbę żądań, wielkość transferu i wolne zapytania. Ustal akceptowalny budżet wydajności dla sklepu, zamiast traktować stały próg milisekund jako uniwersalny.

Moduły mają różny wpływ na zasoby. Narzędzie administracyjne może nie dodawać żadnych zasobów do witryny sklepu, a funkcja warunkowa działać tylko przy wybranych żądaniach. Licz hooki, zapytania i zasoby, które faktycznie się wykonują. Profiluj powtarzane wywołania bazy w pętlach produktów i synchroniczne żądania zewnętrzne podczas renderowania strony.

Tryb debugowania i profilowanie są odrębne. Starszy profiler zapytań i czasu używa _PS_DEBUG_PROFILING_ w config/defines.inc.php. Profiler Symfony dotyczy kwalifikujących się żądań Symfony, gdy jest skonfigurowany. Żaden nie gwarantuje rozbicia czasu dla każdego żądania witryny sklepu lub kończącego się błędem. Używaj profilowania krótko w chronionym środowisku testowym.

Do zarządzania zasobami i integracji CCC preferuj registerStylesheet() i odpowiednie API skryptów. Sprawdź też jawne wersjonowanie i unieważnianie przy wdrożeniu. Rejestracja nie gwarantuje automatycznie odświeżania pamięci podręcznej, a surowy link nie staje się 404 tylko dlatego, że ją wyczyścisz.

Hosty zasobów zaobserwowane na bieżącej stronie możesz wypisać tym przykładem w konsoli przeglądarki:

const hosts = {};
for (const entry of performance.getEntriesByType('resource')) {
    const host = new URL(entry.name, location.href).host;
    if (host && host !== location.host) {
        hosts[host] = (hosts[host] || 0) + 1;
    }
}
console.table(hosts);

Sprawdź własne subdomeny CDN oraz podmioty trzecie. Ta lista obejmuje zasoby obserwowane w przeglądarce, a nie ruch między serwerami ani wszystkie formy przekazywania danych. Zapytaj, dlaczego potrzebny jest nowy host, jakie dane otrzymuje i jak funkcja działa przy jego niedostępności. Powtórz obserwację dla odpowiednich stanów zgody i zalogowania, ponieważ żądanie może pojawiać się dopiero po interakcji lub zmianie uprawnień.

Na kopii testowej użyj blokowania żądań w przeglądarce, aby zasymulować niedostępność zewnętrznego hosta danej funkcji, a następnie ponownie sprawdź stronę. Zapisz, czy opcjonalna funkcja sygnalizuje awarię czytelnie i czy nawigacja oraz zakupy nadal działają. To sprawdza tylko zależność przeglądarki; poproś programistę o osobne przećwiczenie limitów czasu po stronie serwera i nieudanych wywołań w tle.

Przetestuj aktualizacje i przygotuj pełne wycofanie

Przed zastąpieniem plików przeczytaj historię zmian i wymagania. Wykonaj kopię plików i bazy, zapisz zainstalowaną wersję i zachowaj oba ZIP-y. Przetestuj aktualizację z rzeczywistej wersji produkcyjnej, a nie tylko świeżą instalację nowego wydania.

Użyj obsługiwanego procesu aktualizacji w Menedżerze modułów lub przesłania ZIP. Sprawdź wzrost zainstalowanej wersji w bazie i ukończenie odpowiednich migracji upgrade/install-X.Y.Z.php. Samo skopiowanie nowych plików przez SFTP nie dowodzi wykonania migracji.

Konfiguracja często znajduje się w bazie, ale kod aktualizacji może ją zmienić lub usunąć. Po aktualizacji porównaj zapisane ustawienia, własne tabele, hooki, uprawnienia i kopie szablonów motywu. Reset traktuj osobno: może odinstalować i ponownie zainstalować moduł, a obsługa danych zależy od implementacji i opcji ich zachowania. Nie jest bezpiecznym zamiennikiem migracji.

Przećwicz nową instalację, aktualizację, wyłączenie, ponowne włączenie i odinstalowanie jako odrębne operacje na jednorazowych kopiach. Porównaj każdy wynik z udokumentowanymi zasadami zachowywania danych. Poprawne odinstalowanie może celowo zachowywać opinie lub rekordy integracji; usunięcie wszystkiego nie jest automatycznie właściwe. Przed testem destrukcyjnego czyszczenia wyeksportuj potrzebne rekordy.

Preferuj Zaawansowane > Wydajność > Wyczyść pamięć podręczną. Odpowiednie może być też skoordynowane czyszczenie CLI:

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

Uruchom je z katalogu głównego sklepu, używając właściwego pliku wykonywalnego PHP i użytkownika systemu plików. Jeśli potrzebne jest odtwarzanie na poziomie plików, zatrzymaj ruch przychodzący i procesy robocze, potwierdź ścieżki pamięci i właściciela, odbuduj pamięć i zweryfikuj sklep przed ponownym otwarciem. Pamięć podręczna PrestaShop jest odtwarzalna, ale równoczesne żądania, brakujące zależności i uprawnienia mogą spowodować błąd odbudowy. Osobno skoordynuj OPcache WWW oraz pamięci całych stron, proxy lub CDN.

Gdy musisz wrócić do starszej wersji

1. Włącz tryb konserwacji w sklepie produkcyjnym objętym problemem i zatrzymaj zadania mogące zapisywać powiązane dane.
2. Zachowaj uszkodzony stan, logi i szczegóły ostatnich transakcji do diagnozy.
3. Przywróć czysty poprzedni katalog modułu bez mieszania wersji. Odłożoną kopię przechowuj poza publicznym katalogiem modułów.
4. Przywróć odpowiadający stan bazy lub zastosuj migrację odwrotną dostarczoną przez programistę. Same pliki nie odwrócą zmian schematu ani danych.
5. Uzgodnij zamówienia, płatności i zmiany stanów powstałe po kopii. Nie nadpisuj nowych transakcji produkcyjnych starym obrazem całego sklepu.
6. Wyczyść odpowiednie pamięci podręczne i powtórz testy funkcji, konfiguracji oraz składania zamówienia.

Nie używaj Odinstaluj ani Usuń jako kroku powrotu do starszej wersji, chyba że rozumiesz działanie czyszczenia. Moduł może celowo usuwać swoje tabele i ustawienia. Uzyskaj dokładny poprzedni ZIP z archiwum wydań lub od wsparcia, zamiast zakładać, że każde konto udostępnia starsze wersje.

Odizoluj błędy i rozwiąż nakładające się modyfikacje

W środowisku testowym odtwórz błąd z oboma podejrzanymi modułami, każdym osobno i bez żadnego. Zapisuj stan po każdej zmianie. Przy większym zestawie wyłącz kontrolowaną grupę, a potem zawężaj. Testuj zależności i kombinacje: ostatnio włączony moduł może ujawnić interakcję, nie będąc jej jedyną przyczyną.

Wiele modułów może współdzielić hook. Pozycja może mieć znaczenie dla wyświetlanego wyniku, ale kolejność nie jest uniwersalną poprawką. Porównaj zmiany koszyka, zwracane dane, nasłuchy zdarzeń, selektory CSS, dołączone biblioteki, szablony i konfigurację. Hooki i usługi Symfony ograniczają bezpośrednie powiązanie z rdzeniem, ale nie gwarantują działania bez konfliktów.

Rdzeń może scalać nadpisania dodające różne metody do jednej klasy. Nakładające się metody, właściwości lub stałe mogą wywołać jawny konflikt. Nie scalaj z góry dwóch metod z założeniem, że następny instalator je zaakceptuje. Uzgodnij poprawkę zgodności z jednym podmiotem odpowiedzialnym za połączoną implementację i udokumentowaną procedurą instalacji, aktualizacji i usuwania.

Sprawdź pliki nadpisań, komentarze wskazujące właściciela, aktywne ustawienia nadpisań i wpisy ścieżek indeksu klas. Sama lista nazw klas nie identyfikuje właścicieli ani nie dowodzi, że plik jest osierocony. Plik na dysku nie wykonuje się automatycznie na każdej stronie. Nadpisanie jest używane po załadowaniu zmapowanej klasy.

Jeśli panel administracyjny jest niedostępny, w miarę możliwości użyj zwykłego wyłączenia lub obsługiwanego polecenia konsoli. Zmiana nazwy katalogu modułu to awaryjne odizolowanie plików, wymagające zapisanej drogi powrotu. Nie odinstalowuje nadpisań ani nie cofa skompilowanych usług i zmian bazy. Zachowaj logi przed czyszczeniem pamięci podręcznej. Przy pustej odpowiedzi sprawdź status HTTP i logi serwera. Wyjście debugowania stosuj tylko na chronionej kopii i wyłącz je później, ponieważ może ujawnić poufną konfigurację.

Odzyskiwanie według objawów opisuje rozwiązywanie problemów PrestaShop.

Automatyzuj kontrole pakietu wydania

Przy tworzeniu modułu używaj PHPUnit do logiki biznesowej, którą można testować niezależnie, na przykład kalkulatorów i formaterów. Dodaj testy integracyjne instalacji, migracji, hooków i przechowywania danych w zakresie sklepu. Używaj testów przeglądarkowych do istotnych ścieżek klienta, takich jak logowanie, dodanie do koszyka i finalizacja zakupu.

Zbuduj macierz dokładnych obsługiwanych kombinacji rdzenia, PHP, bazy danych i motywu. Uwzględnij aktualne wydania docelowe i najstarsze wydanie, którego wsparcie faktycznie deklarujesz. Przechowuj wyniki testów z dokładnym ZIP-em wydania lub commitem, a nie tylko zakresem zgodności kodu.

Proces CI może zbudować archiwum, sprawdzić zależności i składnię, zainstalować je w czystych sklepach, zaktualizować obsługiwane poprzednie wersje modułu i uruchomić podstawowe testy przeglądarkowe. Statyczne wyszukiwanie przestarzałych API uzupełnia testy uruchomieniowe, ale ich nie zastępuje. Deinstalację i udokumentowane zachowanie danych testuj na jednorazowych kopiach.

Oceń oferty, dostawców i warunki zakupu

Porównując oferty, korzystaj z briefu wymagań. Porównaj tę samą funkcję na własnym katalogu przy użyciu demonstracji lub wersji próbnej, jeśli są dostępne. Instaluj kandydatów osobno, zanim przetestujesz planowane połączenia. Demo dostawcy pokazuje zamierzone działanie; zapytaj o kontrolowaną ocenę w Twoim sklepie i o to, czy licencja dopuszcza instalację na prywatnej kopii testowej.

• Zgodność: uzyskaj dokładne wymagania rdzenia, PHP i motywu, w tym znane ograniczenia.
• Utrzymanie: czytaj datowane wydania, odpowiedzi na zgłoszenia i poprawki bezpieczeństwa. Stara data wydania wymaga kontekstu i sama nie dowodzi porzucenia projektu.
• Dokumentacja: szukaj wymagań, konfiguracji, zasad przechowywania danych, zadań w tle i kroków odzyskiwania.
• Opinie: preferuj opisy rzeczywistej konfiguracji i wyniku wsparcia zamiast średniej gwiazdek.
• Dostęp do kodu: sprawdź, czy programista może go przejrzeć i utrzymywać. Nieudokumentowane zmiany rdzenia lub nieprzejrzyste zależności wymagają zbadania.
• Bezpieczeństwo: wyszukaj dokładną nazwę techniczną i wersję w Friends of Presta oraz komunikatach opiekuna modułu. Brak opublikowanego ostrzeżenia nie dowodzi bezpieczeństwa. Porównaj zagrożone wersje, wagę problemów i dostępne poprawki; sama liczba ostrzeżeń może odzwierciedlać dokładność badania modułu.

Weryfikacja marketplace i programy jakości są przydatnymi sygnałami, ale sklep nadal wymaga testów w środowisku testowym. Bezpośredni dostawca, sprzedawca marketplace, utrzymywany projekt open source lub wykonawca indywidualny mogą być odpowiedni. Porównuj zakres licencji, cenę z podatkiem, odnowienie, aktualizacje, wsparcie, prace indywidualne i warunki rozstrzygania sporów dla rzeczywistej oferty. Oceń implementację i utrzymanie konkretnego modułu.

FAQ wsparcia i aktualizacji Marketplace opisuje Business Care i warunki zwrotów dla dodatków kupionych w Marketplace. Dla zakupów objętych tym FAQ Business Care obejmuje pierwszy rok i odnawia się automatycznie. Wnioski o zwrot trzeba składać pisemnie; kwalifikujące się przypadki obejmują wskazane problemy w ciągu miesiąca, a przy usterkach znaczenie ma wcześniejszy kontakt ze sprzedawcą. Przed zapłatą ponownie sprawdź te warunki dla konkretnego zakupu, produktu i kraju, zapisz warunki oraz datę i zachowaj korespondencję ze wsparciem. Nie zakładaj zwrotu ani określonego czasu odpowiedzi.

Bezpłatne oferty mogą być projektami społecznościowymi, edycjami lite, integracjami powiązanymi z usługą lub produktami wycofanymi. Przeczytaj rzeczywiste limity i obowiązki wsparcia. Wymóg konta u podmiotu zewnętrznego może być uzasadniony. Zbadaj cel przetwarzania danych, odbiorców, okres przechowywania i warunki umowne, zamiast uznawać rejestrację za dowód pozyskiwania danych do obcych celów.

Oszacuj całkowity koszt na podstawie rzeczywistych kosztów licencji, wdrożenia, hostingu, utrzymania, wsparcia i migracji. Bezpłatny nie oznacza z natury niebezpieczny, a płatny nie gwarantuje długotrwałego wsparcia. Uwzględnij szkolenia, cykliczne usługi zewnętrzne, eksport danych i usuwanie rozwiązania. Porównuj kandydatów w tym samym okresie według rzeczywistych warunków dostawców i stawek zespołu.

Bezpłatne narzędzie może służyć określonemu zadaniu: Security Scan raportuje lokalnie wykryte problemy bezpieczeństwa z lokalizacją i wagą oraz podaje kroki ręcznej naprawy. Nie łata sklepu ani nie poświadcza bezpieczeństwa rozważanego modułu. Użyj wyniku jako wskazówki do analizy, a następnie potwierdź odpowiednie działanie na kopii testowej.

O co zapytać programistę lub agencję

• Którą wersję przetestowaliście z dokładnie tą kombinacją rdzenia, PHP i motywu, a które zainstalowane moduły lub integracje wymagają osobnych prac nad zgodnością?
• Czy możecie zademonstrować ścieżkę odbiorczą na naszych reprezentatywnych danych, łącznie z awarią i odzyskiwaniem działania, zamiast pokazać tylko ekran ustawień?
• Czy licencja obejmuje nasze sklepy i prywatną domenę testową i kto otrzymuje pliki, aktualizacje oraz wsparcie po zmianie agencji?
• Które ustawienia, tabele, nadpisania, zadania cykliczne i usługi zewnętrzne się zmieniają i co pozostaje po wyłączeniu lub odinstalowaniu?
• Kto naprawia konflikt między dostawcami, jakie prace wsparcia są wliczone i kto utrzymuje własną poprawkę zgodności?
• Jakie dowody otrzymamy przy przekazaniu i kto odpowiada za wycofanie oraz uzgodnienie nowych zamówień, jeśli start się nie powiedzie?

Przeprowadź audyt już zainstalowanych modułów

Wypisz aktywne i nieaktywne moduły, właścicieli, wersje, cel biznesowy, zależności i gotowość do aktualizacji. Każdy oznacz do zachowania, konfiguracji, aktualizacji, wymiany lub wycofania, wskazując osobę odpowiedzialną za decyzję. Usuwaj zbędne funkcje dopiero po sprawdzeniu zależności. Najpierw wyłącz w odwracalnym teście, następnie odinstaluj obsługiwaną akcją i usuń nieużywane pliki zgodnie z planem przechowywania danych.

Nie wnioskuj o nieużywaniu modułu z pustego bloku w sklepie. Pozornie bezczynny moduł może eksportować zamówienia, dostarczać akcję administracyjną lub okresowo generować plik produktowy. Przed wycofaniem zapytaj pracownika odpowiedzialnego za ten proces i zaobserwuj jego odpowiednie zaplanowane wykonanie. Usunięcie zależności tylko dlatego, że nie ma widocznego widżetu, może zepsuć działającą integrację.

Zwykłe wyłączenie blokuje standardową ścieżkę ModuleFrontController dla nieaktywnego modułu. Nie usuwa samodzielnych endpointów PHP, zainstalowanych nadpisań ani całego kodu integracji. Pozostałe pliki wymagają przeglądu bezpieczeństwa, nawet jeśli nie mają zmierzonego kosztu wykonania.

Te przykłady tylko do odczytu używają ps_. Zastąp go rzeczywistym prefiksem. W multistore sprawdź też powiązania sklepów. Globalna flaga aktywności nie jest pełnym spisem każdego sklepu.

SELECT name, version, active
FROM ps_module
ORDER BY active ASC, name;

SELECT hm.id_module, hm.id_hook, h.name AS hook_name
FROM ps_hook_module hm
LEFT JOIN ps_module m ON m.id_module = hm.id_module
LEFT JOIN ps_hook h ON h.id_hook = hm.id_hook
WHERE m.id_module IS NULL;

SELECT m.name, COUNT(*) AS registrations
FROM ps_hook_module hm
JOIN ps_module m ON m.id_module = hm.id_module
GROUP BY m.name
ORDER BY registrations DESC;

Rejestracje hooków mogą obejmować osobne wiersze sklepów, a duża liczba nie dowodzi kosztownego wykonania. Badaj osierocone rejestracje, zamiast ręcznie usuwać wiersze. Porównuj strukturę bazy przed instalacją i deinstalacją oraz po nich, uwzględniając udokumentowane zachowane dane. Kontrole plików pod override/classes/ i override/controllers/ uzupełniają spis bazy.

Przy przeglądaniu SQL preferuj wiązanie parametrów tam, gdzie jest dostępne. W starszym kodzie sprawdzaj zabezpieczanie wartości właściwe dla kontekstu, rzutowanie na liczby całkowite i obsługę identyfikatorów. Prześledź, jak niezaufane dane trafiają do każdego zapytania i jak chroniony jest dany kontekst.

Dobieraj funkcje do rzeczywistych braków w sklepie

Najpierw sprawdź wbudowane możliwości. Nie ma uniwersalnego zestawu niezbędnych modułów ani progu liczby produktów, który czyni rozszerzenie obowiązkowym.

Dokumentacja natywnej finalizacji zakupu na jednej stronie wyjaśnia zmiany zgodności w wersji 9.2. Szczegóły konfiguracji znajdziesz na podlinkowanych stronach pomocy modułów.

Podejmuj decyzje przed uruchomieniem, zanim wpłyną na dane produkcyjne

Ustal stabilną politykę adresów URL przed publikowaniem linków. Rdzeń generuje adresy z bieżących tras i danych encji. Produkty nie zapisują niezmiennego pełnego adresu przy utworzeniu. Same liczbowe identyfikatory nie tworzą zduplikowanej treści. Przed zmianą tras przejrzyj kategorie domyślne, przekierowanie kanoniczne i linki generowane przez motyw. Zmapuj stare opublikowane adresy, gdy zmiana wymaga przekierowań.

Ustal zasady metadanych i danych strukturalnych wcześnie, a następnie sprawdzaj rzeczywisty wynik. Istniejące encje mogą otrzymać zbiorcze szablony metadanych w SEO Revolution; rozróżniaj zmiany zapisanych metadanych od dynamicznego wyniku. Nie musisz uzupełniać wszystkiego ręcznie.

Uzgodnij zasady fakturowania z księgowym przed wystawieniem faktur. Tworzenie zależy od ustawień faktur i flagi faktury w statusie zamówienia. Rdzeń obsługuje prefiksy, numer początkowy i coroczne zerowanie. Przy zmianach wystawionych dokumentów lub numeracji stosuj zasady korekt i audytu właściwej jurysdykcji.

Zdecyduj, jakich danych klientów rzeczywiście potrzebujesz przy rejestracji. Natywny tryb B2B udostępnia pola firmy i identyfikacyjne; własne dane wymagają odpowiedniego rozszerzenia pól i zgodnego z prawem celu zbierania. Customer Extra Info (IP Ban) nie jest kreatorem pól rejestracji. Zaplanuj, jak obecni klienci uzupełnią nowe wymagane dane.

W miarę możliwości skonfiguruj analitykę i dostęp do Search Console przed kampaniami. Śledzenie nie odtworzy niezebranych zdarzeń interakcji. Przestrzegaj wymagań zgód i zweryfikuj stan odniesienia przed wykorzystaniem go do decyzji. Przetestuj finalizację zakupu przed uruchomieniem. Płatny zamiennik wymaga wykazanej korzyści funkcjonalnej lub zgodności dla Twojego sklepu.

Dodawaj czat, lojalność, widżety społecznościowe i inne elementy prezentacji, gdy potrafisz wskazać ich cel i zmierzyć efekt. Wprowadzaj jedną zmianę naraz. Po wdrożeniu produkcyjnym powtórz kluczowe kontrole i monitoruj logi. Jeśli potrzebujesz pomocy z modułem MPR, prześlij jego wersję, środowisko, kroki odtworzenia, wyniki oczekiwane i rzeczywiste oraz zanonimizowane logi przez wsparcie.

Zdecyduj, czy przetestowana zmiana może trafić na produkcję

Traktuj wyniki testów jako podstawę decyzji o wydaniu, nie średnią ocen. Nierozwiązany błąd zakupu, nieprawidłowy dostęp do danych klientów, niewyjaśnione przekazywanie danych lub niesprawdzony sposób odzyskiwania blokują start, nawet gdy pozostałe kontrole przeszły poprawnie. Mniejsze ograniczenia zapisz wyraźnie, z osobą odpowiedzialną i uzgodnionym działaniem.

1. Ustal niezmienny przetestowany pakiet i zapisz jego wersję, zależności, ustawienia oraz dokładną konfigurację sklepu użytą w testach. Sprawdź zmiany produkcyjne od czasu wykonania kopii.
2. Uzyskaj akceptację wyników klienta i pracowników od osoby odpowiedzialnej biznesowo. Upewnij się, że osoby obsługujące zamówienia wiedzą, co się zmienia i gdzie pojawiają się błędy.
3. Wybierz termin wdrożenia, wykonaj odpowiadającą sobie kopię plików i bazy oraz potwierdź przećwiczone kroki wycofania. Wstrzymaj odpowiednie zadania i ruch, jeśli migracja tego wymaga.
4. Zastosuj obsługiwaną instalację lub aktualizację i zapisaną konfigurację na produkcji. Sprawdź właściwy kontekst sklepu, dane dostępowe i endpointy; wartości testowe nie mogą niepostrzeżenie stać się ustawieniami produkcyjnymi.
5. Wykonaj kluczowe kontrole produkcyjne właściwe dla modułu, stosując autoryzowaną procedurę dostawcy. Sprawdź wynikowe zamówienie, e-mail lub rekord w dalszym systemie, a także widoczną stronę.
6. Świadomie wznów odpowiednie zadania, monitoruj logi i kolejki integracji oraz wskaż osobę reagującą na nieudaną kontrolę. Jeśli wycofasz zmianę, zachowaj i uzgodnij transakcje utworzone w tym okresie.

Przekaż zespołowi końcowe ustawienia, zachowany pakiet, dowody testów, znane ograniczenia, kontakt do wsparcia i procedurę odzyskiwania. Powtórz odpowiednie kontrole po kolejnej zmianie rdzenia, PHP, motywu lub integracji; stary raport odbiorczy opisuje konfigurację, która przeszła test w tamtym czasie.

Pytania właścicieli sklepów

Ile modułów to za dużo?

Użyj inwentaryzacji do znalezienia modułów bez celu biznesowego lub opiekuna, a pomiarów testowych do wykrycia kosztownych interakcji. Sama liczba nie powie, czy intensywnie działający sklep jest sprawny ani czy niemal pusty ma poważną usterkę.

Czy mogę wykonać kontrole samodzielnie?

Możesz porównać widoczne działanie, zapisane ustawienia i żądania przeglądarki na kopii testowej. Poproś programistę o sprawdzenie zmian schematu, uprawnień, wywołań serwerowych i migracji, których nie potrafisz ocenić. Udana lista kontroli w przeglądarce to przydatny dowód, ale nie pełny audyt kodu lub bezpieczeństwa.

Czy odznaka Marketplace, płatna licencja lub niedawny skan gwarantują bezpieczeństwo?

Nie. Każde z nich odpowiada na część pytań zakupowych. Wymagaj dowodów dla rzeczywistej konfiguracji, zbadaj krytyczne wyniki i przed startem zapewnij opiekuna oraz drogę odzyskania działania.

Czy zaktualizować stary moduł, czy go zastąpić?

Zapytaj, czy obsługiwana aktualizacja spełnia wymaganie i zachowuje dane oraz modyfikacje. Jeśli nie, porównaj wymianę lub prace programistyczne o ustalonym zakresie, w tym koszty migracji i usunięcia. Zachowaj wersję, którą potrafisz przywrócić, podczas prób wybranej drogi.

Czy udane odinstalowanie dowodzi możliwości wycofania zmiany?

Przetestuj odtwarzanie, którego rzeczywiście użyjesz po nieudanej aktualizacji. Odinstalowanie może usunąć rekordy, a cofnięcie wersji może wymagać zgodnych plików i zmian bazy. Test odinstalowania wykonuj na jednorazowej kopii, a dla danych sprzedażowych używaj udokumentowanej procedury odzyskiwania.

Czy mogę dodać te funkcje do sklepu, który już sprzedaje?

Tak. Określ wpływ na istniejące rekordy, opublikowane adresy URL, wystawione dokumenty i połączone systemy, a następnie przećwicz zmianę na kopii. W razie potrzeby użyj obsługiwanych aktualizacji zbiorczych lub migracji i zaplanuj przełączenie; dodanie funkcji nie wymaga automatycznie przebudowy sklepu.