PrestaShop news: co warto śledzić, a co jest tylko szumem

News o PrestaShop dzieli się na dwie kategorie, które łatwo pomylić: komunikat produktowy („nowa wersja, więcej możliwości”) i zmiana techniczna (co konkretnie zmieniło się w kodzie). Decyzję wdrożeniową podejmujesz wyłącznie na podstawie drugiej.

Praktycznie śledzisz pięć typów informacji:

• Release notes — opis wydania: co doszło, co naprawiono, jakie są znane problemy.
• Changelog — lista commitów i zmienionych plików. Źródło prawdy, gdy zastanawiasz się, czy Twój moduł się nie wysypie.
• Roadmapa — deklaracja kierunku. Nie jest zobowiązaniem: nie planuj na jej podstawie wdrożenia w konkretnym kwartale.
• Bezpieczeństwo — komunikaty o podatnościach i łatki. Priorytet najwyższy, bez dyskusji.
• Moduły i hosting — kompatybilność z nową wersją PHP i rdzeniem. Tu najczęściej leży realny problem, nie w samym wydaniu.

Cztery kanały oficjalne, do których wracamy przy projektach: blog PrestaShop (ogłoszenia wydań plus warstwa marketingowa), GitHub releases (numery tagów, daty, changelog), dokumentacja deweloperska PrestaShop (wymagania PHP, zmiany w API, migracje) oraz forum (problemy zgłaszane po aktualizacji, zanim ktoś je opisze w release notes).

Filtr, który stosujemy do każdego newsa, jest krótki: numer wersji, data, zakres zmian, wpływ na wersję PHP i na moduły. News bez numeru wersji i daty to nie news, tylko zapowiedź. Nie zrobisz z niej testu na kopii sklepu, nie przypiszesz do niej checklisty wdrożeniowej i nie odpowiesz klientowi, kiedy będzie poprawka. Punkt startowy do dalszej lektury: hub PrestaShop.

Najważniejsze zmiany w PrestaShop: przegląd wersji i statusów

Numer wersji czytaj jako trzy liczby rozdzielone kropkami. Pierwsza to gałąź główna (8, 9), druga to wydanie z nowymi funkcjami, trzecia to poprawki błędów i bezpieczeństwa. Przykład: 8.1.4 to czwarte wydanie poprawkowe w gałęzi 8.1. Zmiana trzeciej liczby zwykle nie zmienia zachowania sklepu i nadaje się na szybszą aktualizację. Zmiana drugiej lub pierwszej to inny zakres: nowe API, nowe ekrany, czasem migracja bazy.

Rozróżnienie gałęzi: 1.7 — w niej rdzeń przeszedł na Symfony i nowy system szablonów; dziś to techniczny dług, bo linia nie dostaje już bieżących poprawek bezpieczeństwa. 8.x — ustabilizowany kierunek, w większości projektów realny punkt docelowy aktualizacji. 9.x — kolejna gałąź; przed planowaniem sprawdź minimalną wersję PHP i listę modułów, które producent zdążył pod nią zaktualizować.

Status wsparcia: PrestaShop nie etykietuje wydań tak jednoznacznie jak projekty z jasnym podziałem LTS/STS, dlatego status konkretnej gałęzi bierz z komunikatu wydania, a nie z wpisu na blogu sprzed dwóch lat. Kolejność decyzji jest zawsze ta sama: 1) czy wydanie zawiera poprawki bezpieczeństwa, 2) czy moja wersja PHP jest wspierana, 3) czy moduły i integracje mają wersje zgodne, 4) dopiero na końcu nowe funkcje.

W tabeli nie podajemy dat wydań jako pewnika — zmieniają się przy każdym patchu. Aktualne numery, daty i statusy bierz z release notes i changelogu na GitHubie PrestaShop, które są źródłem nadrzędnym wobec bloga i forum. Jeśli planujesz przejście na wyższą gałąź, rozłóż je na etapy tak jak w materiale o organizacji wdrożenia krok po kroku.

Co nowe wydania zmieniają dla właściciela sklepu

Zmień perspektywę: nie „co doszło w wersji”, ale „co to robi z moim sklepem”.

Szybkość i konwersja. Przejście z PHP 7.4 na 8.x przyspiesza wykonywanie kodu, ale w sklepie wąskim gardłem rzadko bywa interpreter. Częściej są to zapytania SQL (katalog, filtry, stany magazynowe) i brak cache. Wydanie, które dokłada warstwę cache lub poprawia zapytania w rdzeniu, da efekt; wydanie, które zmienia tylko ekran w panelu, nie ruszy TTFB ani o milisekundę. TTFB i inne wskaźniki odczuwalne dla użytkownika opisuje dokumentacja Core Web Vitals.

Przeliczenie na pieniądze. Sklep robi 1 200 sesji dziennie, konwersja 1,8%, średnia wartość zamówienia 230 zł — to około 22 zamówień i 5 000 zł obrotu na dzień. Jeśli po wdrożeniu TTFB wzrośnie o 400 ms i konwersja spadnie o 0,15 p.p., tracisz 1,8 zamówienia dziennie, czyli około 410 zł, a w skali miesiąca ponad 12 000 zł. Taki rachunek robimy na kopii sklepu przed i po aktualizacji, nie na wyczucie.

Integracje. Największe ryzyko to płatności, kurierzy i ERP. Zmiana w API potrafi zerwać webhook, zmienić format odpowiedzi albo przestać mapować statusy zamówień. Przy wdrożeniach z integracją PrestaShop z Przelewy24 zawsze sprawdzamy jedną transakcję testową, jedną zwrotną i jeden anulowany płatności.

Panel i zespół. Nowe ekrany i uprawnienia oznaczają 30 minut szkolenia i test uprawnień pracownika (Employee permissions) — inaczej magazyn traci dostęp do zamówień.

Bezpieczeństwo. Poprawki CVE mają najwyższy priorytet: wdrożenie w 48 godzin. Jeśli Twoja wersja nie dostaje już łatek, aktualizacja przestaje być opcją.

Kiedy aktualizować PrestaShop po newsie, a kiedy poczekać

News mówi, że jest nowa wersja. To nie znaczy, że masz ją wdrażać w tym tygodniu. Oceń pięć obszarów swojego sklepu w skali 0–2 i zsumuj punkty. Wynik mówi, co dalej.

Suma punktów wyznacza tryb działania:

• 0–2 pkt — wdrażaj po testach. Sklep praktycznie nie ma niestandardowego kodu, ryzyko jest niskie, ale testy na stagingu i tak muszą się odbyć.
• 3–5 pkt — testuj na stagingu. Warunek: staging działa na docelowej wersji PHP i bazy, a nie na „podobnej”.
• 6+ pkt — poczekaj na poprawki. Zwykle 2–6 tygodni po wydaniu wychodzą łatki na błędy wyłapane przez społeczność; nie Ty masz być pierwszym testerem.

Okno wdrożenia ustaw poza szczytem sprzedaży. Dla większości sklepów oznacza to styczeń–luty albo lipiec–sierpień, nigdy dwa tygodnie przed Black Friday, świętami czy sezonem. Wdrożenie robisz dopiero po backupie plików i bazy — i po sprawdzeniu, że backup da się odtworzyć. Sam plik .sql na dysku to nie backup, to nadzieja.

Kiedy nie czekasz. Aktualizacja bezpieczeństwa nie podlega punktacji. Jeśli wydanie łata zdalne wykonanie kodu, SQL injection albo eskalację uprawnień w panelu, wdrażasz w ciągu 24–72 godzin. Nie robisz wtedy pełnego upgrade'u wersji, tylko punktowy hotfix, a jeśli go nie ma — izolujesz ruch: WAF przed sklepem, dostęp do /admin ograniczony po IP, wyłączone nieużywane moduły.

Kto decyduje. Właściciel akceptuje okno i ryzyko utraty sprzedaży — bez jego pisemnej zgody nikt nie rusza produkcji. Deweloper ocenia punkty i wykonuje prace techniczne. Opiekun techniczny (hosting, administrator serwera) weryfikuje wersję PHP, backup i monitoring. Jeśli te trzy role zlewają się w jedną osobę, przy 6+ punktach realnie nie ma kto powiedzieć „stop”. Pomocna bywa wtedy organizacja wdrożenia PrestaShop krok po kroku.

Pułapki przy aktualizacji PrestaShop, których nie ma w changelogu

Changelog opisuje rdzeń. Twoje ryzyko siedzi w override'ach, cache, szablonie, tłumaczeniach i integracjach. Pięć miejsc, które najczęściej przewracają sklep po aktualizacji — i sposób wykrycia ich przed produkcją.

• Moduły z override i starymi hookami. Zacznij od grep -rn "class .*Override" modules/ override/. Potem przejrzyj logi: od 1.7 w var/logs/, w 1.6 w log/. Usunięty w rdzeniu hook nie wywala błędu od razu — moduł po prostu przestaje działać, np. nie dopisuje pola do zamówienia. Listę hooków przestarzałych w danej gałęzi znajdziesz w PrestaShop Developer Documentation.
• Cache, szablon i tłumaczenia. Wyczyść cache z panelu (Zaawansowane → Wydajność → Wyczyść cache) oraz skompilowane szablony (Smarty → Wyczyść cache). Szablon ze zmienionymi plikami .tpl może nie mieć nowych pól formularza — objaw to brak przycisku płatności albo pusty mail. Tłumaczenia siedzą w bazie, nie w plikach: po migracji część fraz wróci do angielskiego, bo zmieniły się klucze.
• Płatności i kurierzy. Testuj wyłącznie na sandboxie. Zrób po jednym zamówieniu na każdą metodę (BLIK, karta, płatność odroczona, za pobraniem), sprawdź powiadomienia zwrotne i zmianę statusu po opłaceniu. Kurierzy: wygeneruj etykietę i list przewozowy, nie tylko sprawdź, że moduł się włącza.
• ERP i księgowość. Rozpisz mapowanie statusów: który status PrestaShop to „do wysłania”, „w realizacji”, „anulowane”. Sprawdź ciągłość numeracji faktur, brak duplikatów, NIP i stawki VAT oraz stany magazynowe po obu stronach.
• Baza danych. Porównaj collation tabel (utf8mb4 vs utf8_general_ci) — mieszanka psuje JOIN-y. W ps_configuration sprawdź dane serializowane: niezgodna długość łańcucha cicho zwraca puste pole. Skrypty migracji leżą w install/upgrade/sql/ — jeśli któraś padła w połowie, nie powtarzaj jej „na oko”.

Przy płatnościach przejdź przez organizację wdrożenia PrestaShop Przelewy24, a przy modułach pisanych na zamówienie — przez generator modułów PrestaShop i zasady pracy z override.

Checklista wdrożenia newsów PrestaShop krok po kroku

Poniższa sekwencja zakłada, że decyzja o wdrożeniu już zapadła. Odklikuj pozycje po kolei — pominięcie choćby jednego punktu „przed” przenosi koszt naprawy z 1 godziny na 1 dzień przestoju sprzedaży.

Przed. Backup plików (tar z katalogiem sklepu) i bazy (mysqldump). Warunek zaliczenia to nie plik na dysku, a udane odtworzenie na stagingu. Staging musi działać na docelowej wersji PHP i PrestaShop — nie na „podobnej”, bo większość błędów to właśnie różnice wersji. Sprawdź php -v i logi błędów po wgraniu.

Testy krytycznych ścieżek. Zamówienie testowe za 1 zł: koszyk → płatność (sandbox) → potwierdzenie → e-mail → faktura. E-mail potwierdzający musi dotrzeć, faktura musi mieć poprawny numer i VAT. Dodaj drugie zamówienie z inną metodą wysyłki — kurier i tak wyjdzie dopiero tutaj.

W trakcie. Wdrożenie w trybie maintenance, poza godzinami szczytu. Realistyczny cel to poniżej 30 minut niedostępności sklepu. Po aktualizacji uruchom ponownie crony i kolejkę maili, jeśli korzystasz z wysyłki masowej.

Po — 72 godziny monitoringu. Logi PHP, błędy 500, odrzucone płatności, wskaźnik porzuconych koszyków. Sprawdź też, czy nie pogorszyły się Core Web Vitals — aktualizacja szablonu potrafi dorzucić zapytania do bazy i podnieść LCP. Miej gotowy plan rollback: kopia, snapshot serwera, procedura przywrócenia przećwiczona wcześniej, nie wymyślana w panice.

Jeśli nie masz opiekuna technicznego, który odklika to za Ciebie, zobacz PrestaShop — wdrożenia i opieka techniczna.

Jak weryfikować PrestaShop news, żeby nie wpaść w fake newsy

Zanim cokolwiek wdrożysz, ustal, z jakiego źródła pochodzi informacja. Kolejność jest stała: GitHub release → oficjalny blog/release notes → dokumentacja deweloperska → forum → grupy na Facebooku i Discordzie. Pierwsze trzy mają numery wersji i daty, ostatnie dwa służą do potwierdzenia objawu, nie do podejmowania decyzji o wdrożeniu.

• GitHub release — tag wydania, lista commitów, zmienione pliki. Sprawdzasz, czy zmiana dotyczy rdzenia, czy tylko skóry i modułów. To najszybszy sposób, żeby ocenić realny zakres prac.
• Oficjalny blog i release notes — kontekst biznesowy i kolejność wydań. Dobry punkt startowy, ale nie wystarcza do planu wdrożenia.
• Dokumentacja deweloperska — opisy hooków, API i deprecjacji. Jeśli funkcja, z której korzysta Twój moduł, jest oznaczona jako przestarzała, masz termin na przebudowę. Punktem odniesienia jest dokumentacja deweloperska PrestaShop.
• Forum i grupy społecznościowe — źródło objawów („po aktualizacji nie działa X”), nigdy źródło decyzji.

Podatności weryfikuj w NVD oraz w GitHub Security Advisories dla repozytorium PrestaShop. Dopiero gdy oba źródła potwierdzają CVE i podają zakres wersji, planujesz pilne wdrożenie.

Czerwone flagi, które powinny zatrzymać wdrożenie: brak numeru wersji („nowa aktualizacja” bez X.Y.Z), brak daty publikacji, screeny bez linku do źródła, presja na natychmiastowe kliknięcie i brak odniesienia do changelogu.

Gdy news dotyczy modułu z Marketplace, otwórz changelog modułu i sprawdź deklarowaną zgodność z Twoją wersją rdzenia. Testuj na kopii sklepu — najlepiej z użyciem generatora modułów PrestaShop do przygotowania środowiska testowego. Bez tego kroku aktualizujesz na produkcji i liczysz na szczęście.

PrestaShop news w polskich sklepach: integracje, hosting, SEO

News techniczny przestaje być newsem, gdy dotknie płatności, kurierów albo ERP. W polskim sklepie najczęściej pęka jedno z trzech miejsc.

Integracje. Przelewy24, PayU, InPost, DPD i DHL komunikują się przez własne API i webhooki. Każda zmiana w obsłudze zamówień, statusów i hooków płatności może zerwać mapowanie statusów (np. „opłacone” vs „oczekujące na płatność”). Po aktualizacji zrób test na kwotę 1–5 zł i sprawdź, czy webhook wrócił i czy zamówienie zmieniło status automatycznie. Przy ERP sprawdź eksport zamówień i stany magazynowe — duplikaty faktur wychodzą dopiero po kilku dniach. Organizację takiego wdrożenia opisujemy w tekście o module PrestaShop Przelewy24.

Hosting i VPS. Przed wdrożeniem porównaj wymagania wydania z tym, co masz: wersja PHP, wersja MySQL/MariaDB, memory_limit (w praktyce minimum 256M przy większym katalogu), max_execution_time dla importów oraz zadania cron i kolejki (generowanie etykiet, mailing). Brak zgodności PHP to najczęstsza przyczyna białej strony po aktualizacji.

SEO techniczne. Po wdrożeniu sprawdź przekierowania 301 na starych adresach kategorii i produktów, sitemapę, znacznik canonical oraz to, czy roboty nie dostały blokady w pliku robots.txt. Wydajność odłóż na Core Web Vitals — liczy się czas reakcji serwera i stabilność układu. W Google Search Console wyzeruj raport błędów i patrz na niego 7–14 dni po wdrożeniu.

Przegląd z deweloperem zaplanuj, gdy: brakuje zgodności PHP, masz moduły bez aktualizacji od ponad roku albo w GSC rosną błędy indeksacji. Całość kontekstu — na stronie PrestaShop w DropDigital.

Najczęstsze błędy i jak je wykryć

Lista kontrolna do odklikania

• Ustal źródło newsa — Sprawdź, czy informacja pochodzi z release notes, GitHub releases, dokumentacji deweloperskiej czy forum. Blog marketingowy to nie źródło decyzji wdrożeniowej.
• Zapisz numer wersji i datę wydania — Wpisz je na piśmie do zgłoszenia. News bez numeru i daty nie jest podstawą decyzji.
• Sprawdź status wsparcia i wymagane PHP — Ustal, czy gałąź jest nadal wspierana i jakie PHP jest wymagane. To warunek wstępny przed planowaniem czegokolwiek.
• Przeczytaj changelog pod kątem zmian niekompatybilnych — Szukaj słów: deprecated, removed, backward incompatible, breaking change. Notuj, których modułów i hooków dotyczą.
• Zrób inwentaryzację modułów — Lista: nazwa, wersja, autor, czy moduł używa override i z jakich hooków korzysta. Bez tej listy nie ocenisz ryzyka.
• Sprawdź zgodność PHP na stagingu — Staging musi działać na docelowej wersji PHP, nie na tej, którą akurat miałeś pod ręką.
• Wykonaj backup plików i bazy oraz przetestuj odtworzenie — Kopia bez testu odtworzenia to tylko plik. Zmierz czas przywrócenia i porównaj go z długością okna serwisowego.
• Postaw staging na docelowej wersji PHP i PrestaShop — Ta sama wersja rdzenia, te same moduły, możliwie blisko produkcyjnych danych — inaczej test nic nie wnosi.
• Przejdź pełną ścieżkę zamówienia testowego — Koszyk, płatność, wybór kuriera, etykieta, faktura, e-mail do klienta i do sklepu. Każdy krok potwierdzony zrzutem lub logiem.
• Przetestuj integrację ERP i księgowości — Sprawdź mapowanie statusów zamówień, stany magazynowe i generowanie dokumentów. Tu najczęściej wychodzą błędy niewidoczne w sklepie.
• Wybierz okno wdrożenia — Poza szczytem sprzedaży, po backupie, w porze, gdy jest kto odebrać telefon od klienta.
• Ustal plan rollback przed startem — Zapisz procedurę i próg, przy którym ją uruchamiasz. Decyzja o wycofaniu nie powinna zapadać w panice o 23:00.
• Monitoruj 72 godziny po wdrożeniu — Logi błędów PHP, kolejka e-maili, liczba zamówień, błędy płatności. Spadek konwersji w pierwszych dwóch dniach to sygnał, nie przypadek.
• Sprawdź cache i tłumaczenia — Po zmianie wersji wyczyść cache i przejrzyj kluczowe szablony pod kątem brakujących tłumaczeń i nadpisań.

Najczęściej zadawane pytania

Źródła i materiały

• Google Search Central – tworzenie treści dla ludzi
• Google Search Central – dane strukturalne
• Google Search Central – Core Web Vitals
• PrestaShop – dokumentacja dla deweloperów
• Google Ads – dokumentacja API