WooCommerce chce wymagać PHP 8.1. Sprawdź swoją wersję, zanim sklep utknie na starej gałęzi

Sprzedaję online od dwudziestu lat i wiem, jak wygląda ta rozmowa: „u nas wszystko działa, po co ruszać". Działa, dopóki jedna aktualizacja nie przestanie się instalować, a wtedy okazuje się, że sklep stoi na wersji PHP, której nikt nie łata od trzech lat. 8 września zespół WooCommerce opublikował propozycję, która ustawia termin tej rozmowy na najbliższe tygodnie. Pokazuję, co dokładnie zaproponowano, ile sklepów to dotyczy i co zrobić, żeby nie robić tego w listopadzie.

Co dokładnie ogłoszono

Brian Coords opublikował na blogu dla programistów WooCommerce wpis „Proposed change: Requiring PHP 8.1 or newer for WooCommerce 11.5 and beyond". Propozycja: podnieść minimalną wersję PHP do 8.1 „starting with the WooCommerce 11.5 release currently targeted for January 2027".

Dwie rzeczy warto przeczytać dokładnie. Po pierwsze, to propozycja, nie decyzja — zespół zapowiada, że przejrzy opinie i dane o użyciu, zanim potwierdzi wydanie docelowe i minimalną wersję. Po drugie, podany termin to styczeń 2027, czyli tuż po sezonie. Jeżeli masz to zrobić spokojnie, oknem jest wrzesień i początek października, a nie grudzień.

Liczby z wpisu: „PHP 7.4 currently accounts for approximately 7% of tracked stores, while PHP 8.0 accounts for approximately 2%". Wśród sklepów z relatywnie świeżym WooCommerce (z ostatniego roku) łączny udział jest „closer to 6% and trending consistently downward". Autor od razu zastrzega, że telemetria WooCommerce jest dobrowolna, więc „these figures do not represent every store, but a representative sample". Traktuję to jak próbę, nie spis powszechny — i podejrzewam, że w segmencie sklepów zaniedbanych technicznie odsetek starego PHP jest wyższy niż w tej próbie, bo to właśnie te sklepy najrzadziej włączają telemetrię.

Co się stanie, jeśli nic nie zrobisz

Nie będzie awarii z dnia na dzień i nie będzie wymuszonej aktualizacji. Wpis opisuje to wprost: „A store running PHP 7.4 or 8.0 would not be automatically upgraded to a WooCommerce version that requires PHP 8.1". Sklep zostaje na ostatniej zgodnej wersji WooCommerce i dostaje wydania poprawkowe tylko tej gałęzi.

Brzmi łagodnie i właśnie dlatego jest niebezpieczne. Zamrożenie na starej gałęzi oznacza w praktyce trzy rzeczy. Nowe funkcje przestają do Ciebie docierać. Wtyczki i motywy, które aktualizujesz normalnie, zaczynają w pewnym momencie wymagać nowszego rdzenia — i albo je zatrzymujesz, albo psujesz sklep. A poprawki bezpieczeństwa dla starej gałęzi mają swój koniec, którego nie ogłasza się z rocznym wyprzedzeniem.

Dlaczego celem nie jest PHP 8.1

To najważniejsze zdanie w całym tekście. Minimalne wymaganie WooCommerce i sensowna wersja do postawienia sklepu to dwie różne liczby.

Zaglądam na oficjalną stronę wspieranych wersji PHP: PHP 8.0 i PHP 8.1 są dziś po końcu wsparcia. PHP 8.2 dostaje już tylko poprawki bezpieczeństwa i kończy je 31 grudnia 2026, czyli za niecałe cztery miesiące. Aktywne wsparcie mają 8.4 (do 31 grudnia 2026) i 8.5 (do 31 grudnia 2027), a PHP 8.3 jest w fazie poprawek bezpieczeństwa do 31 grudnia 2027.

Wniosek jest prosty: jeśli w tym kwartale ruszasz PHP, przechodzisz na 8.3 albo 8.4, nie na 8.1. Migracja na wersję, której nikt już nie łata, to praca wykonana po to, żeby powtórzyć ją za rok. Przy okazji dostajesz coś więcej niż zgodność — nowsze PHP jest po prostu szybsze, a na karcie produktu i w koszyku każde sto milisekund ma swoją cenę.

Ile to naprawdę kosztuje

W typowym sklepie na współdzielonym hostingu przełączenie wersji PHP to pole wyboru w panelu i pięć minut pracy. Koszt siedzi gdzie indziej: w kodzie, który przestanie działać.

Ryzyko rośnie wraz z wiekiem i liczbą własnych rozwiązań. Sklep na świeżym motywie i dwudziestu popularnych wtyczkach zwykle przechodzi bez zająknięcia. Sklep z motywem-dzieckiem pisanym siedem lat temu przez wykonawcę, z którym nie masz już kontaktu, i z trzema własnymi integracjami do ERP i kuriera — to inna historia. Tam realnie trzeba przejrzeć kod pod kątem rzeczy, które w PHP 8 przestały być ostrzeżeniem, a stały się błędem.

Dlatego kolejność ma znaczenie i wygląda tak:

1. Sprawdź, na czym stoisz. W panelu WordPressa: WooCommerce → Stan (Status) → sekcja Server environment, pozycja PHP version. Ta sama informacja jest w panelu hostingu.
2. Zrób kopię na środowisku testowym. Większość hostingów ma dziś staging jednym kliknięciem. Bez tego kroku nie ruszaj produkcji.
3. Przełącz PHP na kopii i włącz logowanie błędów. Przeklikaj ścieżkę: lista produktów, karta, dodanie do koszyka, płatność, panel zamówień, generowanie faktury, integracja z magazynem.
4. Zaktualizuj wtyczki i motyw dopiero po tym, jak wiesz, że sam sklep wstaje na nowym PHP. Zmiana dwóch rzeczy naraz oznacza, że przy awarii nie wiesz, co ją wywołało.
5. Przełącz produkcję poza godzinami szczytu i zostaw sobie tydzień na wyłapanie drobiazgów, zanim wejdziesz w sezon.

Czego bym nie robił

Nie robiłbym tego w listopadzie ani w grudniu. Jeśli masz wpisane w kalendarz zamrożenie zmian przed Q4 — a warto je mieć — to zmiana wersji PHP jest dokładnie tą rzeczą, która musi zdążyć przed zamrożeniem albo poczekać do stycznia.

Nie zmieniałbym też przy okazji trzech innych rzeczy. Znam pokusę: „skoro i tak wchodzimy w środowisko, to podmieńmy jeszcze bramkę płatności". Każda zmiana wykonana razem z inną zmianą kosztuje później podwójnie w diagnostyce.

I nie traktowałbym tego jako problemu wyłącznie WooCommerce. Kalendarz PHP jest wspólny dla całego świata sklepów napisanych w tym języku — PrestaShop i Magento mają swoje własne progi, ale ten sam podkład. Jeżeli prowadzisz sklep na którejkolwiek z tych platform, dziś jest dobry dzień, żeby po prostu sprawdzić liczbę w panelu.

Co zrobić w najbliższym tygodniu

• Sprawdź wersję PHP sklepu (WooCommerce → Stan albo panel hostingu) i zapisz ją w notatce razem z wersją WooCommerce.
• Zapytaj hosting, jakie wersje PHP udostępnia i czy da się je przełączyć na środowisku testowym bez ruszania produkcji.
• Zrób listę wtyczek i integracji pisanych na zamówienie — to one, a nie rdzeń, decydują o kosztach.
• Wyznacz datę przełączenia przed zamrożeniem zmian na Q4 i wpisz ją do kalendarza jako zadanie z właścicielem, nie jako „kiedyś".
• Jeżeli stoisz na PHP 8.2, potraktuj 31 grudnia 2026 jako swój termin, nawet gdyby WooCommerce nigdy nie podniósł minimum.

Utrzymanie sklepu nie jest tematem, który sprzedaje się sam w rozmowie o marketingu. Ale przez dwadzieścia lat nie widziałem sytuacji, w której zaniedbana warstwa techniczna kończyłaby się taniej niż zaplanowana. Jeżeli chcesz przejść przez to raz i porządnie, odezwij się do nas — przejdziemy razem przez listę i ustalimy, co da się zrobić bez ryzyka przed sezonem.

Decyzje

• 2026-09-09 09:20 — U01EDFDH8G2: zaakceptowany — Slack 2026-09-09 08:59-09:00, wątek monitora 09.09: "a-052 publikuj"