Wersja PHP wpływa jednocześnie na bezpieczeństwo, wydajność i zgodność WordPressa. Na dzień przygotowania tego poradnika WordPress.org rekomenduje PHP 8.3 lub nowsze, MySQL 8.0+ albo MariaDB 10.11+ oraz HTTPS. To jednak nie znaczy, że na każdej istniejącej stronie możesz jednym kliknięciem przełączyć PHP bez testu. Rdzeń WordPressa może być gotowy, a stary motyw lub wtyczka — nie.
Szybka odpowiedź
Dla nowej instalacji wybieraj aktualną, wspieraną wersję PHP zgodną z wymaganiami WordPressa i używanych rozszerzeń. Dla istniejącej strony najpierw zrób backup i test na stagingu. Po zmianie przejdź kluczowe ścieżki: wp-admin, formularze, logowanie, wyszukiwarkę, sklep, płatności, zadania w tle i wysyłkę e-maili. Dopiero wtedy przełącz produkcję.
Dlaczego stara wersja PHP jest ryzykiem
Niewspierane wersje PHP nie otrzymują normalnych poprawek bezpieczeństwa od projektu PHP. Nawet jeśli WordPress „jeszcze działa”, środowisko staje się trudniejsze do utrzymania. Z drugiej strony gwałtowny skok o kilka wersji może ujawnić przestarzały kod, dlatego modernizacja powinna być zaplanowana, a nie odkładana do momentu awarii.
Sprawdź nie tylko WordPressa, ale cały stos
Kompatybilność rdzenia to tylko początek. Wtyczki, motyw, mu-plugins, własne fragmenty PHP i biblioteki Composer mogą używać funkcji usuniętych lub zmienionych w nowszym PHP. Sprawdź changelogi producentów, logi deprecations i fatal errors. Narzędzie do automatycznej analizy pomaga, ale nie zastępuje testu działającej strony.
Staging przed przełączeniem produkcji
Kopia stagingowa powinna mieć możliwie podobne PHP, bazę i konfigurację serwera. Na niej wykonaj aktualizacje rozszerzeń, zmień PHP i przetestuj funkcje. Jeżeli staging jest bardzo różny od produkcji, wynik testu może być fałszywie uspokajający. Ważne jest także, by staging nie wysyłał prawdziwych maili i nie wykonywał produkcyjnych płatności.
Logi po zmianie wersji
Nie kończ testu na tym, że homepage się otwiera. W logach mogą pojawić się ostrzeżenia, deprecated notices albo błędy w zadaniach cron, których nie widać na froncie. Sprawdź kilka cykli zadań, formularze i działania administracyjne. Dobra migracja PHP to taka, po której nie rośnie liczba błędów w tle.
Plan rollbacku
Przed przełączeniem zapisz poprzednią wersję PHP i konfigurację, zrób kopię plików oraz bazy i ustal, jak szybko wrócić. Rollback nie powinien polegać na „może panel hostingu pozwoli”. Na stronie firmowej potrzebujesz konkretnej drogi odwrotu, szczególnie gdy zmiana odbywa się poza godzinami pracy zespołu.
Jak potwierdzić, że naprawa naprawdę działa?
Po przełączeniu PHP porównaj logi przez co najmniej jeden pełny cykl pracy strony. Wejdź w edytor, zapisz treść, wyślij formularz, wykonaj zadanie cron i — jeśli to sklep — przejdź testowe zamówienie w trybie bezpiecznym. Błędy zgodności mogą wystąpić tylko w rzadziej używanej ścieżce, dlatego homepage i wp-admin to za mało, by zatwierdzić zmianę.
Co obserwować po zmianie?
Zapisz poprzednią i nową wersję PHP, konfigurację rozszerzeń oraz datę przełączenia. Jeżeli po kilku dniach pojawi się regresja, łatwiej będzie ją powiązać ze zmianą. Monitoruj deprecated notices jako sygnał technicznego długu, nawet jeśli nie zatrzymują strony dziś — kolejna wersja PHP może zamienić ostrzeżenie w błąd.
Kiedy przekazać temat dalej?
Eskaluj, gdy strona zależy od starego, nieutrzymywanego rozszerzenia, którego nie da się uruchomić na aktualnym PHP. Wtedy decyzja dotyczy migracji funkcji lub kodu, a nie „znalezienia jeszcze starszego serwera”. Długoterminowe utrzymywanie niewspieranego środowiska jest ryzykiem bezpieczeństwa.
Praktyczny scenariusz diagnostyczny
Przy zmianie PHP nie testuj tylko strony głównej. Typowy konflikt ujawnia się dopiero podczas zapisu produktu, wysyłki formularza, generowania PDF albo uruchomienia zadania cron. Na stagingu przełącz wersję PHP, sprawdź logi deprecated/warning/fatal i przejdź przez krytyczne scenariusze. Jeśli wszystko działa, dopiero wtedy zmieniaj produkcję i zostaw możliwość szybkiego rollbacku. Aktualne wymagania WordPressa są dobrym punktem odniesienia, ale kompatybilność całej witryny zależy od motywu, wtyczek i własnego kodu. Szczególnie stare dodatki mogą działać „na oko”, a generować ostrzeżenia albo błędy w rzadziej używanych funkcjach. Dlatego aktualizacja PHP to małe wdrożenie, nie zmiana jednej cyfry w panelu hostingu.
Bezpieczna kolejność działań
- Sprawdź aktualne wymagania WordPress.org i wsparcie PHP.
- Zaktualizuj kompatybilne wtyczki i motyw po backupie.
- Odtwórz stronę na stagingu i zmień PHP tam jako pierwsze.
- Przetestuj front, wp-admin, formularze, cron i integracje.
- Przejrzyj logi PHP po zmianie.
- Przełącz produkcję z gotowym rollbackiem i monitoringiem.
Czego nie robić
Nie zmieniaj wersji PHP na produkcji tuż przed kampanią albo w godzinie największego ruchu bez testu. Nie pozostawiaj też starego PHP „na zawsze” dlatego, że jedna nieutrzymywana wtyczka blokuje upgrade — to sygnał, że trzeba wymienić komponent.
Powiązane poradniki HeatLogic
Potrzebujesz pomocy?
Jeśli nie wiesz, czy starsza strona przejdzie na aktualne PHP, HeatLogic może wykonać test zgodności na stagingu, zaktualizować problematyczne komponenty i przełączyć środowisko z planem rollbacku.
Źródła techniczne
Najczęściej zadawane pytania
Czy WordPress działa na PHP 7.4?
WordPress może uruchamiać się na starszych wersjach, ale WordPress.org rekomenduje obecnie PHP 8.3+. Dla bezpieczeństwa warto używać aktualnie wspieranej gałęzi, o ile cała strona jest zgodna.
Czy zmiana PHP zmienia treść w bazie?
Nie. Zmienia środowisko wykonawcze, ale może ujawnić błędy w kodzie wtyczek, motywu lub własnych dodatków.
Czy staging jest konieczny?
Przy ważnej stronie zdecydowanie warto go użyć, szczególnie przy większym skoku wersji PHP.
Co jeśli jedna wtyczka nie działa na nowym PHP?
Najlepiej ją zaktualizować, zastąpić albo poprawić. Trzymanie całego serwisu na niewspieranym PHP przez jeden komponent zwiększa ryzyko.