Jeśli prowadzisz sklep na WooCommerce, temat PHP 8.1 może wyglądać jak kolejna techniczna rzecz, którą „ktoś tam ogarnie”. Tyle że tym razem nie chodzi o kosmetykę. WooCommerce zapowiedziało, że wersja 11.6, planowana na luty 2027 roku, ma wymagać PHP 8.1 lub nowszego. Sklep działający na PHP 7.4 albo 8.0 nie spełni więc minimalnego wymagania tej wersji.

Nie oznacza to jednak, że wystarczy wejść do panelu hostingu, kliknąć nową wersję i uznać temat za zamknięty. PHP to tylko jeden klocek. Do sprawdzenia zostają jeszcze wtyczki, motyw, płatności, wysyłka, podatki, integracje i własne modyfikacje. Najrozsądniejszy plan? Najpierw diagnoza, potem kopia zapasowa, staging, testy i dopiero na końcu zmiana na produkcji.

PHP 8.1 w WooCommerce — o co właściwie chodzi?

PHP to środowisko, w którym działa WordPress i WooCommerce. Właściciel sklepu zwykle nie zagląda tam codziennie, ale wersja PHP wpływa na to, czy aktualne wydania oprogramowania mogą działać zgodnie z wymaganiami. WooCommerce 11.6 ma wymagać PHP 8.1 lub nowszego. To zapowiedź konkretnego minimum dla tej wersji, a nie obietnica, że każdy sklep po zmianie zacznie działać bez żadnych problemów.

WooCommerce 11.3 ma wyświetlać sklepom na PHP 7.4 lub 8.0 komunikat o przyszłej zmianie. Z kolei WooCommerce 11.5 ma być ostatnią planowaną wersją kompatybilną z tymi starszymi wersjami PHP. Daje to czas na przygotowanie, ale nie rozwiązuje sprawy na stałe. Odkładanie tematu do momentu, w którym aktualizacja już czeka za drzwiami, to proszenie się o nerwową akcję w najgorszym możliwym momencie.

Minimum a rekomendowana wersja PHP

Warto rozdzielić dwie rzeczy. PHP 8.1 ma być minimalnym wymaganiem zapowiedzianym dla WooCommerce 11.6. Jednocześnie dokumentacja WooCommerce rekomenduje PHP 8.3 lub nowsze dla aktualnych instalacji. Minimum oznacza więc: „ta wersja ma spełniać wymaganie”. Rekomendacja mówi: „nowsze środowisko jest preferowanym kierunkiem”.

Nawet PHP 8.1 albo nowsze nie potwierdza zgodności całego sklepu. Konkretna wtyczka, motyw, integracja z płatnościami lub wysyłką czy własny kod mogą zachować się inaczej po zmianie środowiska. Dlatego nie warto traktować numeru PHP jak magicznego zaklęcia. To początek przygotowań, nie ich koniec.

Najpierw sprawdź, na czym stoi Twój sklep

Pierwszy krok jest prosty i nie wymaga grzebania w kodzie. W panelu WordPressa wejdź w WooCommerce > Status, znajdź sekcję Server environment i odczytaj pozycję PHP version. Zobaczysz, z jakiej wersji PHP sklep korzysta teraz. Jeśli widzisz 7.4 albo 8.0, nie oznacza to automatycznie awarii, ale jest to wyraźny sygnał, że trzeba zaplanować zmianę.

Nie zatrzymuj się jednak na jednej liczbie. Właściciel sklepu powinien zebrać również informacje o wersji WooCommerce, WordPressa, motywu, wtyczek i najważniejszych integracji. Zapisz, jakie masz metody płatności, reguły wysyłki, naliczanie podatków, e-maile transakcyjne, zadania automatyczne i własne modyfikacje. To właśnie te elementy potrafią zrobić różnicę między spokojną aktualizacją a telefonem z pytaniem: „Dlaczego klient nie może zapłacić?”.

Dwie ścieżki kontroli w panelu

Podstawową ścieżkę już znasz: WooCommerce > Status > Server environment > PHP version. To miejsce przydatne także wtedy, gdy rozmawiasz z hostingiem albo osobą techniczną, bo pozwala szybko ustalić stan wyjściowy.

Drugie miejsce to Tools > Site Health > Info. WordPress pokazuje tam szczegóły środowiska serwera, między innymi informacje o PHP i jego rozszerzeniach, motywie, wtyczkach, zadaniach cyklicznych oraz REST API. Site Health może pomóc wyłapać sygnały ostrzegawcze przed zmianą i po niej. Sama lista nie zastąpi testu zakupowego, ale daje szerszy obraz sytuacji.

Czy można zostać na PHP 7.4 albo 8.0?

Według zapowiedzi WooCommerce 11.6 ma wymagać PHP 8.1 lub nowszego. Odpowiedź brzmi więc: PHP 7.4 i 8.0 nie spełnią minimalnego wymagania tej wersji. WooCommerce 11.5 ma być ostatnią planowaną wersją kompatybilną z PHP 7.4 i 8.0. Pozostanie na niej może być rozwiązaniem przejściowym, jeśli hosting, wtyczka albo integracja potrzebują czasu na przygotowanie.

To jednak tylko bufor. Starsza wersja WooCommerce nie usuwa problemu, a starsze gałęzie PHP mają ograniczony cykl wsparcia. Po jego zakończeniu nie otrzymują poprawek bezpieczeństwa. Nie chodzi więc o to, żeby w panice zmieniać wszystko jednego dnia, tylko żeby nie udawać, że temat sam zniknie.

Rozwiązanie przejściowe kontra plan na przyszłość

Jeżeli sklep nie jest jeszcze gotowy, pozostanie na WooCommerce 11.5 może dać czas na uporządkowanie środowiska. W tym okresie trzeba sprawdzić hosting, wtyczki, motyw, integracje i własny kod, a nie po prostu odłożyć sprawę do kolejnego przypomnienia.

Przed aktualizacją warto ustalić, czy hosting obsługuje PHP 8.1 lub nowsze, jak wygląda zmiana wersji i czy można szybko wrócić do poprzedniej. Nie zakładaj, że każdy panel hostingowy oferuje bezpieczny rollback. Lepiej wiedzieć to wcześniej niż odkryć po fakcie, że przycisk „cofnij” istnieje tylko w marzeniach.

Plan bez paniki: backup, staging i testy

Najbezpieczniejsza kolejność jest dość nudna, ale właśnie dlatego działa. Najpierw sprawdzasz wersje i zależności. Potem kontaktujesz się z hostingiem, wykonujesz kopię plików i bazy danych oraz upewniasz się, że sklep można odtworzyć. Dopiero później przechodzisz do zmiany PHP na stagingu.

Staging powinien możliwie wiernie odwzorowywać produkcję. Jeśli na kopii brakuje motywu, wtyczki płatniczej albo integracji wysyłkowej, test może dać fałszywe poczucie bezpieczeństwa. Sklep na stagingu ma zachowywać się jak prawdziwy sklep, a nie jak dekoracja z samą stroną główną.

Kolejność działań przed produkcją

1. Sprawdź wersję PHP w WooCommerce > Status oraz dodatkowe informacje w Site Health.
2. Zapisz wersje WooCommerce, WordPressa, motywu, wtyczek i kluczowych integracji.
3. Skontaktuj się z hostingiem i ustal sposób zmiany PHP oraz możliwość powrotu do poprzedniej wersji.
4. Wykonaj aktualną kopię plików i bazy danych oraz sprawdź możliwość odtworzenia sklepu.
5. Przygotuj staging z możliwie pełnym odwzorowaniem motywu, wtyczek, integracji i ustawień.
6. Przełącz PHP na stagingu, przejdź pełne testy, sprawdź błędy i logi, a dopiero potem planuj produkcję.

Nie da się obiecać całkowitego wyeliminowania ryzyka. Da się za to nie dokładać sobie problemów przez zmianę „na żywym organizmie”, bez kopii i bez planu odwrotu.

Checkout pod lupą — co dokładnie kliknąć?

Najczęstszy błąd to sprawdzenie strony głównej, wejście na jeden produkt i stwierdzenie, że wszystko działa. Sklep internetowy nie zarabia jednak dlatego, że ładnie się otwiera. Zarabia wtedy, gdy klient może przejść od produktu do zamówienia, zapłacić, a sklep poprawnie obsłuży resztę procesu.

Po zmianie PHP trzeba więc przejść pełną ścieżkę zakupową. Najlepiej zrobić to dla każdej używanej metody płatności, a nie tylko dla jednej. Jeżeli sklep ma warianty produktów, kupony, różne sposoby wysyłki albo niestandardowe reguły podatkowe, każdy z tych elementów powinien trafić na listę kontrolną.

Lista kontrolna procesu zakupowego

• Wejście do sklepu, wyszukiwanie produktu, karta produktu i warianty.
• Dodawanie do koszyka, zmiana liczby produktów, usuwanie pozycji i użycie kuponu.
• Uzupełnienie danych klienta oraz przejście przez wszystkie dostępne opcje wysyłki.
• Sprawdzenie naliczania podatków i podsumowania zamówienia.
• Test każdej metody płatności, z której korzysta sklep.
• Odbiór i poprawność e-maili transakcyjnych.
• Tworzenie, edycja i zmiana statusu zamówienia w panelu.
• Obsługa zwrotu oraz procesów automatycznych, w tym zadań cyklicznych.
• Działanie motywu, rozszerzeń, REST API, własnych integracji i własnego kodu.

Po zmianie sprawdź także panel administracyjny. Front sklepu może wyglądać dobrze, a problem może czekać w edycji zamówienia, zadaniu automatycznym albo integracji uruchamianej dopiero po zakupie. Właśnie dlatego test powinien obejmować nie tylko kliknięcie „kupuję”, ale również to, co dzieje się chwilę później.

Zmiana PHP na produkcji i plan awaryjny

Jeżeli staging przeszedł testy, możesz zaplanować zmianę na produkcji. Dobrze ustalić ją z hostingiem i wybrać okres poza największym ruchem. Przed przełączeniem upewnij się jeszcze raz, że kopia jest aktualna, a plan powrotu do poprzedniej wersji PHP jest realny, a nie tylko domniemany.

Po zmianie produkcyjnej ponownie sprawdź WooCommerce > Status, stronę sklepu, koszyk, checkout, płatności, wysyłkę, podatki, zamówienia i procesy automatyczne. Warto monitorować błędy i mieć możliwość szybkiej reakcji. PHP 8.1 nie jest gwarancją poprawnego działania każdego elementu, bo wynik zależy również od wersji WordPressa, WooCommerce, motywu, wtyczek, integracji i własnych modyfikacji.

Co zrobić, jeśli testy wykażą problem?

Nie przełączaj wtedy PHP na produkcji tylko dlatego, że termin goni. Najpierw ustal, czego dotyczy problem: motywu, konkretnej wtyczki, płatności, wysyłki, zadania automatycznego, integracji czy własnego kodu. Sprawdź informacje w Site Health, błędy i logi, a następnie zweryfikuj element odpowiedzialny za niezgodność.

Jeśli sklep ma wiele zależności albo nie pozwala na szybki rollback, pomoc techniczna może ograniczyć ryzyko organizacyjne. Najważniejsze, żeby nie zgadywać i nie testować zmian bez kopii. W przypadku sklepu sprzedażowego „jakoś to będzie” to plan mniej więcej tak dobry jak parasol z papieru.

Podsumowując: najpierw sprawdź wersję PHP i wszystkie zależności, potem wykonaj kopię oraz przetestuj zmianę na stagingu. Nie pomijaj checkoutu, płatności, wysyłki, podatków, e-maili, zamówień i procesów automatycznych. Dopiero po takim sprawdzeniu przełącz produkcję, najlepiej z planem powrotu i możliwością szybkiej reakcji. PHP 8.1 ma być wymaganiem dla WooCommerce 11.6, ale nie jest automatycznym potwierdzeniem zgodności całego sklepu. Masz stronę, sklep albo materiały graficzne, które proszą się o ogarnięcie? Napisz do INB Marketing i zobaczymy, co da się z tym sensownie zrobić.