Zamrożenie zmian przed Q4: co łatać do końca września, czego nie ruszać do stycznia

Wrzesień to ostatni miesiąc, w którym wolno mi coś zepsuć w sklepie. Od października ruch rośnie, w listopadzie godzina awarii kosztuje wielokrotność tego, co w lipcu, a wykonawca, który ma naprawić błąd w Black Week, ma w tym samym czasie dziesięciu innych klientów z tym samym problemem. W DrTusz trzymamy się zasady z praktyki, nie z podręcznika: zmiany funkcjonalne kończymy do końca września, potem tylko łatki bezpieczeństwa i poprawki krytyczne. Poniżej przekładam ostatnie wydania trzech platform na tę zasadę — na język właściciela, który nie musi rozumieć kodu, ale musi wiedzieć, o co zapytać wykonawcę.

WooCommerce: 11.1 jest na dniach, ale to nie jest łatka

Aktualna wersja stabilna to 11.0.1 z 10 sierpnia. Wydanie 11.1, planowane na 1 września, zostało przesunięte na 3 września, bo w testach RC1 wyszły problemy z mini-koszykiem. Sam ten komunikat mówi, w jakim stanie jest wydanie: zespół znalazł błędy w koszyku dwa dni przed premierą.

Co jest w 11.1: galerie zdjęć dla wariantów trafiają do rdzenia. Po aktualizacji wtyczka Additional Variation Images jest automatycznie wyłączana, dane migrują w tle po 250 wariantów na przebieg, a flaga funkcji znika z bazy. Jeśli Twój motyw albo wtyczka czyta zdjęcia wariantów bezpośrednio z metadanych, po aktualizacji może pokazywać stare galerie albo żadne. To dokładnie ten rodzaj zmiany, której nie chcę odkrywać 20 listopada na karcie najlepiej sprzedającego się produktu.

Druga wiadomość z 2 września — wycofanie „magicznych ciągów” na rzecz klas z nazwanymi stałymi — brzmi groźnie, ale nie łamie niczego. Stare ciągi statusów działają, nowe stałe zwracają te same wartości, a rozszerzenia mogą przejść na nie, kiedy chcą. Pytanie do wykonawcy nie brzmi więc „czy nasze wtyczki używają enumów”, tylko: „czy motyw i wtyczki czytają galerię wariantów wprost z metadanych i czy przetestowałeś 11.1 na stagingu z naszym koszykiem”.

Decyzja: 11.1 na staging we wrześniu, na produkcję po sezonie. Wydania poprawkowe 11.0.x — zawsze, bo tylko najnowsza wersja jest uznawana za w pełni bezpieczną.

PrestaShop: dwie łatki teraz, jedna decyzja na styczeń

18 sierpnia wyszły równolegle 9.1.5 i 8.2.8. Obie łatają tę samą listę pięciu luk: wstrzyknięcie formuł w eksporcie CSV (ocena 8,3), SSRF przez import CSV (8,2), podszywanie adresu IP przez nagłówek X-Forwarded-For (7,3), SQL injection w filtrach panelu (6,5) i kontrolę dostępu do powiadomień (4,3). Trzy oceny wysokie. To wdrażasz w tym tygodniu, po kopii bazy i plików — bez dyskusji o sezonie.

Trzy rzeczy, które z tych komunikatów wynikają pośrednio:

• 9.1.5 jest ostatnim planowanym wydaniem gałęzi 9.1 przed 9.2. Beta 9.2 z 22 lipca wnosi natywny One Page Checkout, asystenta „Ask AI” w panelu i system dodatkowych pól — z wyraźnym ostrzeżeniem, żeby nie instalować jej na produkcji. Na czwarty kwartał 9.2 nie istnieje.
• 8.2.x jest w fazie wsparcia rozszerzonego: dostaje tylko poprawki bezpieczeństwa i krytyczne. Komunikat nie podaje daty końca.
• Dla gałęzi 1.7 łatek nie ma. Czy te pięć luk dotyczy 1.7, trzeba sprawdzić w opisach GHSA — jeśli tak, nikt ich nie naprawi.

Do tego dochodzi PHP. PrestaShop 8 wspiera PHP od 7.2 do 8.1, a 8.2 i nowsze — nie. PrestaShop 9.1 wymaga PHP 8.2–8.5. Tymczasem PHP 8.1 nie ma już wsparcia, a 8.2 traci wsparcie bezpieczeństwa 31 grudnia 2026. Sklep na PrestaShop 8 stoi więc na PHP bez łatek, a przejście na 9 to skok dwóch wersji naraz: platformy i języka. Każdy moduł i motyw musi działać na obu — to jest prawdziwy koszt migracji, nie sama instalacja.

„Re-founding PrestaShop”: co ogłoszono, a czego nie

1 września nowy CEO PrestaShop Mikołaj Król, wcześniej szef Sylius, opublikował list „Re-founding PrestaShop, with you”. Fakty z listu: cyber_Folks sfinalizował przejęcie PrestaShop, w firmie przeprowadzono redukcję zatrudnienia w trybie francuskiej procedury PSE, historycznie 61% kontrybucji do projektu pochodziło od pracowników firmy, a w 2025 roku już 72%. Około 60% przychodu firmy pochodzi z płatności partnerów, około jedna trzecia z oficjalnego marketplace'u. 18 września zapowiedziano webinar z dyrektorem zarządzającym.

Czego w liście nie ma: roadmapy wersji, daty stabilnego 9.2, daty końca wsparcia 8.2, jednego słowa o 1.7. Są deklaracje o postawieniu społeczności w centrum i prośba, żeby agencje i sklepy wybierały oficjalnych dostawców płatności i moduły z marketplace'u, bo to finansuje projekt.

Jak to czytam jako operator? Projekt open source, w którym trzy czwarte kodu pisze firma, jest tak stabilny, jak ta firma. Właściciel jest teraz polski, po restrukturyzacji, a jego model przychodowy opiera się na płatnościach i module. Spodziewałbym się nacisku na oficjalny ekosystem i mniejszej cierpliwości dla starych gałęzi. To argument za tym, żeby decyzję o migracji podjąć w tym roku — i za tym, żeby jej nie wykonywać w czwartym kwartale.

Kiedy zostać na 8.2.x i tylko łatać: sklep działa, moduły są aktualne, PHP 8.1 jest odizolowane na poziomie serwera, a wykonawca potwierdza, że da radę wdrożyć poprawki bezpieczeństwa w dzień od wydania. Kiedy PrestaShop przestaje być odpowiedzią: gdy migracja wymaga przepisania większości integracji i tak — wtedy warto spojrzeć szerzej, o czym pisałem w tekście o headless kontra monolit.

Magento i Mage-OS: łatka, którą musi założyć ktoś konkretny

Mage-OS 3.4.0 z 11 sierpnia portuje sierpniową łatkę Adobe APSB26-92 (izolowana łatka 249-2026-08-001-CE, ocena CVSS 9,1): uprawnienia do galerii mediów w edytorze, zapis opinii o produkcie, edycja konta klienta. Zalecenie brzmi „wszyscy użytkownicy 3.x powinni aktualizować niezwłocznie”. Ważny szczegół: role administratora bez szczegółowych uprawnień do galerii tracą po aktualizacji możliwość wgrywania i usuwania plików — te uprawnienia trzeba skonfigurować przed, nie po.

Sklepy na Magento Open Source pytają wykonawcę o jedno: „czy łatka 249-2026-08-001-CE jest u nas założona i kto to potwierdzi na piśmie”. Natomiast wydanie Adobe z 8 września dotyczy wyłącznie Adobe Commerce as a Cloud Service — sklep na Open Source albo Mage-OS nie dostaje z niego nic automatycznie i nie musi nic robić.

Checklista zamrożenia

• Staging, który jest kopią produkcji z tego tygodnia, nie z marca.
• Kopia bazy i plików przed każdą łatką, z testem odtworzenia, nie tylko z plikiem na dysku.
• Okno serwisowe we wtorek albo środę rano, nigdy w piątek.
• Jedna osoba, która odbiera zmianę: klika przez koszyk, płatność, zwrot i panel po każdej aktualizacji.
• Lista rzeczy, których nie ruszamy do stycznia: motyw, checkout, moduły płatności, wersje główne platformy, PHP.

Co zrobić w najbliższym tygodniu

1. PrestaShop: aktualizacja do 9.1.5 albo 8.2.8 po kopii; jeśli jesteś na 1.7, zapytaj wykonawcę, czy pięć luk z 18 sierpnia dotyczy Twojej wersji i jak je obejść.
2. WooCommerce: 11.0.1 na produkcji, 11.1 na stagingu; test galerii wariantów i mini-koszyka na trzech najlepiej sprzedających się produktach.
3. Magento/Mage-OS: potwierdzenie łatki 249-2026-08-001-CE na piśmie; przegląd uprawnień do galerii mediów przed aktualizacją.
4. Sprawdź wersję PHP na serwerze i datę końca jej wsparcia. Jeśli to 8.1 albo starsze — to punkt pierwszy planu na styczeń.
5. Zapisz datę i zakres zamrożenia w jednym miejscu i wyślij wykonawcy. Zmiany po tej dacie tylko na pisemne „tak” właściciela.

Jeśli chcesz, żeby ktoś przeszedł z Tobą przez ten plan na Twojej wersji, Twoich modułach i Twoim wykonawcy, zobacz, jak pracujemy.