Zmiana wersji PHP na stronie WordPress to jedna z tych czynności, które potrafią jednocześnie przyspieszyć witrynę, poprawić bezpieczeństwo i ograniczyć liczbę problemów technicznych w przyszłości. Najwięcej zależy od trzech rzeczy: tego, co masz teraz, na jaką wersję chcesz przejść i czy Twoje wtyczki oraz motyw są gotowe na zmianę. Poniżej pokazuję praktyczne podejście, które stosuję przy takich aktualizacjach: bez zgadywania, bez chaosu i z planem awaryjnym.
Najważniejsze fakty o zmianie PHP na WordPressie
- PHP 8.3 lub nowsze to obecnie bezpieczny punkt odniesienia dla większości stron opartych na WordPressie.
- Zmienia się je po stronie hostingu, a nie w samym panelu WordPressa.
- Przed aktualizacją trzeba zrobić kopię zapasową, odświeżyć WordPress, motywy i wtyczki oraz sprawdzić zgodność kluczowych rozszerzeń.
- Najlepiej testować zmianę na stagingu, czyli kopii testowej strony.
- Jeśli coś się wysypie, najczęściej winny jest motyw, wtyczka albo własny kod, a nie sam WordPress.
- Po zmianie warto sprawdzić nie tylko stronę główną, ale też formularze, logowanie, koszyk i kluczowe podstrony.
Dlaczego zmiana wersji PHP realnie wpływa na stronę
PHP to silnik, na którym działa WordPress, więc każda podmiana wersji ma wpływ na to, jak szybko i stabilnie pracuje cały serwis. W praktyce nowsze wydania zwykle przynoszą lepszą wydajność, poprawki bezpieczeństwa i lepszą obsługę współczesnego kodu. Nie chodzi więc o kosmetykę, tylko o warstwę, która wpływa na każdą podstronę, formularz i zapytanie do bazy.
O oficjalnym kierunku mówi to bardzo wprost sama dokumentacja WordPressa: rekomendacją jest dziś PHP 8.3 lub nowsze, a starsze wersje poniżej tego poziomu nie są dobrym wyborem na stronę produkcyjną. Z drugiej strony WordPress nadal uruchomi się na 7.4+, ale to nie znaczy, że warto na tym zostawać. Jeśli patrzę na stronę firmową, sklep albo portal z ruchem organicznym, traktuję aktualny PHP jak element higieny technicznej, a nie opcję „do zrobienia kiedyś”.
Różnica w praktyce bywa szczególnie odczuwalna na większych instalacjach: sklepach WooCommerce, rozbudowanych blogach i stronach z cięższym motywem. W takich przypadkach każda poprawa po stronie interpretera może dać krótszy czas odpowiedzi, a czasem także mniej błędów w tle. To dobry punkt wyjścia, ale zanim cokolwiek zmienisz, trzeba sprawdzić, co masz obecnie i czy nie wejdziesz na minę.
Właśnie dlatego następna sekcja nie dotyczy „klikania aktualizacji”, tylko oceny ryzyka i stanu wyjściowego.
Jak sprawdzić, na jakiej wersji działa witryna
Najprościej zacząć z poziomu kokpitu WordPressa. Wchodzę w Stan witryny i otwieram zakładkę z informacjami o serwerze, gdzie w sekcji dotyczącej serwera znajdziesz aktualną wersję PHP. To najszybszy sposób, żeby potwierdzić, co faktycznie obsługuje witrynę, a nie tylko co widnieje w panelu hostingu.
Drugie źródło sygnału to komunikaty w panelu administracyjnym. Jeśli widzisz ostrzeżenie w stylu „PHP Update Required” albo „PHP Update Recommended”, traktuję je jako realny sygnał, a nie dekorację. Taki komunikat zwykle oznacza, że warto przyspieszyć działanie, bo wersja jest już zbyt stara albo zbliża się do granicy bezpieczeństwa.
Przy ocenie stanu strony patrzę też na trzy rzeczy:
- czy WordPress, motyw i wtyczki są aktualne,
- czy korzystasz z wtyczek o aktywnym wsparciu i sensownej historii aktualizacji,
- czy masz własne fragmenty kodu w motywie potomnym, plikach mu-plugins albo w custom snippets.
To ważne, bo najwięcej problemów po zmianie PHP nie wynika z core WordPressa, tylko z elementów dookoła. Gdy już wiesz, gdzie jesteś, można przejść do wyboru docelowej wersji i nie robić tego na ślepo.
Jaką wersję PHP wybrać w 2026 roku
Jeśli miałbym wskazać jeden domyślny wybór dla większości stron, wybrałbym PHP 8.3. To obecnie najbardziej rozsądny kompromis między nowoczesnością, stabilnością i kompatybilnością z ekosystemem WordPressa. W praktyce właśnie od tego poziomu zaczynam większość rozmów o migracji.
Nie każda strona musi jednak kończyć na tym samym wydaniu. Dla witryn z bardzo świeżym motywem i dobrze utrzymanymi wtyczkami można rozważać nowsze wersje, ale tylko po sprawdzeniu kompatybilności na kopii testowej. Ja nie traktuję numeru wyższej wersji jako automatycznego sukcesu, bo ostatecznie liczy się cały stos: WordPress, motyw, wtyczki, własny kod i hosting.
| Wersja PHP | Mój werdykt | Kiedy ma sens |
|---|---|---|
| 8.3 | Najbezpieczniejszy wybór | Większość stron firmowych, blogów i sklepów, gdy chcesz dobrego balansu między zgodnością a aktualnością |
| 8.4 | Dobry kandydat po testach | Gdy hosting ją oferuje, a motyw i wtyczki przechodzą testy bez błędów |
| 8.5 | Opcja dla ostrożnych testów | Tylko jeśli środowisko testowe i krytyczne rozszerzenia są na to gotowe |
| 8.2 | Przejściowo | Gdy nie możesz jeszcze wejść wyżej, ale planujesz szybkie przejście dalej |
| 7.4 | Awaryjnie | Wyłącznie jako krótkie rozwiązanie dla starej instalacji w trakcie migracji |
W dokumentacji WordPressa rekomendacja wciąż wskazuje na 8.3 lub wyżej, a starsze wersje poniżej tego poziomu są coraz słabszym wyborem z punktu widzenia bezpieczeństwa. Jeśli strona ma jakikolwiek ruch, nie zostawiałbym jej na starej gałęzi tylko dlatego, że „na razie działa”. Działa i bezpiecznie działa to dwie różne rzeczy.
Kiedy masz już wybrany cel, można przejść do samej zmiany. I tu najważniejsze jest to, żeby nie robić jej bez przygotowania.
Jak przeprowadzić zmianę bez nerwów
Zmiana wersji PHP dzieje się po stronie hostingu. Sam WordPress nie aktualizuje PHP, bo to element konfiguracji serwera. W praktyce zwykle oznacza to panel hostingu, ustawienia przypisane do domeny albo kontakt z supportem, jeśli dany panel jest ograniczony.
- Zrób pełną kopię zapasową plików i bazy danych.
- Zaktualizuj WordPress, motyw i wszystkie wtyczki.
- Jeśli to możliwe, sklonuj stronę do środowiska testowego, czyli stagingu.
- Sprawdź zgodność najważniejszych wtyczek i własnego kodu.
- Zmodyfikuj wersję PHP w panelu hostingu albo poproś support o wykonanie zmiany.
- Po przełączeniu przetestuj stronę główną, podstrony, formularze, logowanie i sklep, jeśli istnieje.
- Przez kilka godzin obserwuj logi błędów i zachowanie strony w czasie rzeczywistym.
Jeżeli prowadzisz bardziej złożony serwis, nie robię takiej zmiany w godzinach największego ruchu. Wolę okno serwisowe albo wieczór, bo wtedy łatwiej wyłapać błędy i szybciej wrócić do poprzedniej wersji, jeśli coś pójdzie nie tak. To szczególnie ważne przy WooCommerce, systemach rezerwacji i stronach z formularzami leadowymi.
Jeśli nie widzisz opcji zmiany w panelu, nie zakładaj od razu, że się nie da. Często trzeba wejść głębiej w ustawienia konkretnej domeny albo po prostu napisać do hostingu. Właśnie dlatego po zmianie wersji najczęściej sprawdzam nie tylko sam serwis, ale też to, jak reaguje zaplecze i czy nie pojawiają się ukryte błędy.
Co zrobić, gdy po zmianie pojawiają się błędy
Najczęstszy scenariusz wygląda tak: strona główna działa, ale wtyczka, panel admina albo konkretna sekcja zaczyna zgłaszać błąd 500, biały ekran albo dziwne ostrzeżenia. W takiej sytuacji nie panikuję i nie szukam winy w samym PHP jako takim. Najpierw wracam do logów i sprawdzam, który komponent wywala wyjątek.
| Objaw | Najbardziej prawdopodobna przyczyna | Co robię najpierw |
|---|---|---|
| Biały ekran lub 500 | Niekompatybilna wtyczka, motyw albo własny kod | Wracam do poprzedniej wersji PHP i wyłączam problematyczne rozszerzenie |
| Problemy tylko w panelu admina | Wtyczka zarządzająca edycją, cache lub custom admin code | Sprawdzam ostatnio aktualizowane dodatki i błędy w logach |
| Frontend działa częściowo | Motyw lub builder strony | Testuję szablony, widżety i własne fragmenty PHP |
| Ostrzeżenia o deprecated | Stary kod wymagający poprawy, ale niekoniecznie awaria | Plan naprawczy dla dewelopera, zamiast natychmiastowego rollbacku |
Jeżeli problem jest poważny, rollback wersji PHP jest najszybszą drogą powrotu do działania. Dopiero potem szukam źródła konfliktu. To ważne, bo czasem klient próbuje „naprawić wszystko naraz”, a to zwykle tylko wydłuża przestój. Lepsza kolejność jest prosta: najpierw przywrócić dostępność, potem naprawić przyczynę.
W przypadku własnego kodu bardzo często pomaga przejrzenie plików w motywie potomnym, czyli child theme, oraz modułów typu mu-plugin. To właśnie tam lądują niestandardowe fragmenty, które najłatwiej przegapić. Po takich porządkach widać jeszcze wyraźniej, jakich błędów warto unikać od początku.
Najczęstsze błędy przy podnoszeniu wersji
- Zmiana PHP przed aktualizacją wtyczek i motywu - stary kod ma większą szansę się wysypać na nowszym silniku.
- Brak kopii zapasowej - bez backupu każdy błąd zamienia się w problem operacyjny, a nie w zwykłą korektę.
- Testowanie tylko strony głównej - najszybciej psują się formularze, logowanie, checkout i elementy dynamiczne.
- Ślepa wiara w zielony status hostingu - to, że serwer „obsługuje” daną wersję, nie znaczy jeszcze, że wszystkie rozszerzenia są gotowe.
- Zostawanie na starej wersji, bo raz coś nie zadziałało - jednorazowy problem nie jest powodem, żeby utrzymywać ryzyko bezpieczeństwa przez kolejne miesiące.
- Pomijanie własnych snippetów - nawet mały fragment w functions.php potrafi zrobić więcej szkody niż duża wtyczka.
Jeśli miałbym wskazać jeden błąd, który widzę najczęściej, to jest nim pośpiech bez planu cofnięcia zmian. Przy stronie firmowej albo sklepie internetowym to kiepska strategia. Nawet jeśli aktualizacja sama w sobie jest prosta, warto mieć procedurę, która pozwoli przejść z powrotem do poprzedniego stanu w kilka minut, a nie w kilka godzin.
Gdy ten porządek już masz, zmiana PHP przestaje być stresującą operacją, a staje się regularnym elementem utrzymania strony. I właśnie tak traktuję ją w praktyce.
Co zostawiam sobie na checklistę przed kolejną zmianą
- Sprawdzam wersję PHP w Stanie witryny, a nie tylko w panelu hostingu.
- Porównuję ją z rekomendacją WordPressa i z wymaganiami kluczowych wtyczek.
- Aktualizuję core, motyw i rozszerzenia, zanim ruszę konfigurację serwera.
- Zmianę wykonuję najpierw na stagingu, jeśli strona jest biznesowo ważna.
- Po przełączeniu testuję najważniejsze ścieżki użytkownika, nie tylko wygląd strony.
- Przez krótki czas obserwuję logi i zachowanie formularzy, koszyka oraz panelu admina.
Jeśli potraktujesz aktualizację PHP jak normalny element opieki nad WordPressem, a nie jednorazową akcję ratunkową, oszczędzisz sobie wielu problemów. W praktyce najwięcej zyskują strony, które są utrzymywane regularnie: z kopią zapasową, testami i krótką listą kontrolną. To prostsze niż późniejsze gaszenie pożaru, a przy dobrze zarządzanej stronie zwykle kończy się po prostu lepszą wydajnością i spokojniejszym działaniem.
