WordPress i PHP 8 — bezpieczna aktualizacja krok po kroku [2026]

Aktualizacja PHP na stronie WordPress to jedna z najbezpieczniejszych i najbardziej opłacalnych zmian — nowsze PHP jest szybsze, bezpieczniejsze i wymagane przez coraz więcej wtyczek. Ryzyko nie leży w samym WordPressie, który od wersji 6.x wspiera PHP 8.x, ale w wtyczkach, motywie i własnych modyfikacjach. Ten przewodnik pokazuje, jak przeprowadzić aktualizację bez białej strony, jak przygotować kopię, co sprawdzić przed zmianą i co zrobić, gdy coś pójdzie nie tak.

Najważniejsze: Bezpieczna aktualizacja PHP w WordPressie ma pięć kroków: kopia zapasowa z testem odtworzenia → aktualizacja WordPressa, wtyczek i motywu na obecnym PHP → środowisko testowe na docelowej wersji → weryfikacja ścieżek krytycznych → produkcja z monitoringiem. Nigdy nie podnoś PHP bez aktualnych wtyczek — to najczęstsza przyczyna awarii.

Dlaczego warto zaktualizować PHP na stronie WordPress

Trzy argumenty, które przekonują nawet najbardziej ostrożnych.

Bezpieczeństwo. WordPress to najczęściej atakowany CMS na świecie — nie dlatego, że jest dziurawy, ale dlatego, że jest popularny. Podatności w samym WordPressie są łatane szybko, ale wymagają wspieranej wersji PHP. Na wersji po EOL (np. 7.4) nowe luki w interpreterze zostają bez łaty — a to one są najniebezpieczniejsze, bo działają „poniżej" CMS-a.

Wydajność. PHP 8.x jest istotnie szybsze od 7.x — optymalizacje silnika i JIT potrafią skrócić czas generowania strony o kilkanaście–kilkadziesiąt procent bez żadnych zmian w kodzie. Dla strony z ruchem to realne różnice w Core Web Vitals i konwersji.

Kompatybilność. Coraz więcej wtyczek podnosi minimalną wersję PHP — część już dziś wymaga 8.0+ i nie dostaje aktualizacji na starszych wersjach. Zostając na 7.4, tracisz nie tylko nowe funkcje, ale i poprawki bezpieczeństwa wtyczek.

Zanim zaczniesz — kopia zapasowa z testem odtworzenia

Każda aktualizacja PHP zaczyna się od kopii, która faktycznie działa. Backup „gdzieś na serwerze", którego nikt nigdy nie odtwarzał, to nie backup.

Zabezpiecz trzy warstwy

• pliki — cały katalog WordPressa (albo przynajmniej wp-content: wtyczki, motywy, uploads),

• baza danych — pełny zrzut przez wp db export, phpMyAdmin albo narzędzie hostingu,

• konfiguracja — wp-config.php i pliki .htaccess.

• Test odtworzenia: przywróć kopię na środowisku testowym i sprawdź, że strona się otwiera, a logowanie i formularze działają. To 15 minut, które ratuje sytuację, gdy coś pójdzie nie tak — a przy aktualizacji PHP „coś" potrafi pójść nie tak.

Wskazówka: Jeśli nie masz środowiska testowego, zbuduj je na subdomenie (np. test.twojadomena.pl) z blokadą noindex i kopią bazy. Większość hostingów pozwala ustawić inną wersję PHP per katalog — wystarczy to, żeby przetestować nową wersję bez ryzyka dla produkcji.

Krok 1 — zaktualizuj WordPress, wtyczki i motyw (na obecnym PHP)

Przed zmianą wersji PHP doprowadź środowisko do aktualnego stanu — ale na obecnej wersji PHP, na której wszystko działa.

1. Zrób kopię (jak wyżej) — punkt wyjścia.
2. Zaktualizuj WordPress core do najnowszej wersji.
3. Zaktualizuj wszystkie wtyczki i motyw — także te, które „działają od lat". Wtyczka nieaktualizowana od dwóch lat to główny kandydat do problemów na nowym PHP.
4. Usuń wtyczki nieużywane — mniej kodu, mniej ryzyka; nieaktywna wtyczka nadal może być wektorem ataku.
5. Sprawdź zgodność wtyczek — WordPress pokazuje w Narzędzia → Zdrowie witryny → Informacje wymaganą i zalecaną wersję PHP. Wtyczki deklarują wsparcie w swoim repozytorium (kolumna „Tested up to" i „Requires PHP").

Dopiero gdy wszystko jest aktualne i strona działa stabilnie na obecnym PHP — przechodzisz do testów nowej wersji.

Krok 2 — środowisko testowe na docelowej wersji PHP

Na środowisku testowym (subdomena albo kopia lokalna) przełącz PHP na wersję docelową — 8.3 albo 8.4. Jeśli hosting nie pozwala ustawić wersji per katalog, tymczasowo przełącz całą domenę na noc albo w weekend o niskim ruchu — ale zawsze po kopii.

Na środowisku testowym przejdź listę weryfikacyjną.

• Strona główna, podstrony, wpisy, archiwa — czy się renderują.
• Logowanie do panelu i edycja treści.
• Formularze kontaktowe i zapisy do newslettera — czy wysyłają.
• Sklep (jeśli jest): dodanie do koszyka, checkout, płatność testowa.
• Wtyczki krytyczne: SEO, cache, bezpieczeństwo, kopie zapasowe, e-commerce.
• Logi błędów PHP — czy nie ma fatal errors i deprecation.

Jeśli coś nie działa, diagnoza jest prosta: wyłączaj wtyczki pojedynczo, aż znajdziesz winną. Najczęstsze przyczyny to nieaktualizowane wtyczki, stary motyw z własnym kodem i modyfikacje w functions.php (albo child theme).

Co najczęściej psuje się po aktualizacji PHP

Doświadczenie z setkami stron WordPress pokazuje te same wzorce.

• Stare wtyczki — kod pisany pod PHP 5.6/7.x używa usuniętych funkcji (create_function(), each(), mysql_*). Jeśli wtyczka nie ma aktualizacji — wymień ją na aktywnie rozwijaną alternatywę.
• Stary motyw z modyfikacjami — functions.php w motywie rodzica zostanie nadpisany przy aktualizacji, a child theme z błędami trafi na nowe PHP. Sprawdź własne snippety.
• Deprecation w logach — kod działa, ale logi się zapełniają (dynamiczne właściwości, null w parametrach). To lista do naprawy, nie awaria — ale zaśmieca monitoring.
• Fatal errors z „Call to undefined function" — prawie zawsze stara wtyczka albo stary snippet. Diagnoza: wp-content/debug.log po włączeniu WP_DEBUG.
• Problemy z płatnościami i integracjami — najdroższy typ awarii. Dlatego transakcję testową robisz na stagingu, zawsze.

Jeśli po aktualizacji zobaczysz białą stronę: włącz tryb debug w wp-config.php, sprawdź debug.log, wyłącz wtyczki przez zmianę nazwy katalogu wp-content/plugins, przywróć dostęp i diagnozuj pojedynczo. Pełna procedura jest w artykule o naprawie WordPress, a przyczyny białej strony opisuje poradnik o białej stronie w PrestaShop (mechanika błędów jest analogiczna).

Krok 3 — produkcja z monitoringiem

Po zielonych testach na stagingu przełącz PHP na produkcji — poza szczytem ruchu, w oknie, w którym możesz reagować.

Po przełączeniu sprawdź w pierwszych minutach: stronę główną, logowanie, formularz kontaktowy i panel. Przez pierwsze dni obserwuj logi błędów i czas odpowiedzi — narzędzia monitoringu albo hostingowy panel błędów wystarczą. Stara wersja PHP zostaje dostępna na serwerze, więc powrót to jedna zmiana w panelu.

Po stabilizacji (kilka dni bez błędów) wróć do dwóch porządków: wyczyść cache (wtyczka cache, OPcache, CDN — wszystkie warstwy) i sprawdź wynik w PageSpeed Insights — powinieneś zobaczyć poprawę czasów.

Którą wersję PHP wybrać dla WordPressa

Docelowo 8.3 albo 8.4 — obie są wspierane przez WordPressa i ekosystem wtyczek. 8.4 ma pełne wsparcie do końca 2028 roku, więc to wybór „na dłużej". Jeśli któraś z krytycznych wtyczek nie deklaruje jeszcze zgodności z 8.4, wybierz 8.3 i wróć do tematu za kilka miesięcy.

• Unikaj dwóch skrajności: wersji po EOL (7.4, 8.0, 8.1, a wkrótce 8.2) — brak łatek bezpieczeństwa — i wersji najnowszej tuż po premierze (8.5+) na stronach produkcyjnych z rozbudowanym ekosystemem wtyczek. Złoty środek to najnowsza wersja, którą wspierają wszystkie krytyczne wtyczki.

Ile to trwa i ile kosztuje

Dla typowej strony firmowej na WordPressie aktualizacja PHP to praca kilku godzin: kopia, aktualizacje, staging, testy, produkcja. Jeśli wszystko działa — koszt po stronie czasu, nie budżetu.

Sytuacje, w których robi się drożej: wtyczki bez aktualizacji wymagające wymiany (2–8 godzin), stary motyw z modyfikacjami (4–16 godzin), sklep WooCommerce z płatnościami wymagającymi testów transakcyjnych (1–3 dni). Pełny zakres pomocy przy takich aktualizacjach prowadzę w ramach opieki nad stroną WordPress i usługi WordPress.

Szerszy kontekst — daty wsparcia wszystkich wersji PHP i rekomendacje dla platform — znajdziesz w artykule o wersjach PHP i datach wsparcia. Jeśli strona stoi na 8.2, sprawdź deadline w artykule o końcu wsparcia PHP 8.2. A jeśli zastanawiasz się nad platformą — WordPress czy PrestaShop — aktualizacja PHP jest tańsza na WordPressie dzięki prostszej warstwie zależności.

Najczęściej zadawane pytania

Czy aktualizacja PHP zepsuje moją stronę WordPress?

Sama aktualizacja PHP nie zmienia treści ani ustawień — zmienia środowisko wykonawcze. Ryzyko dotyczy kodu: starych wtyczek, motywu i modyfikacji. Dlatego aktualizacja przebiega według kolejności: najpierw aktualizacja wtyczek na starym PHP, potem testy na stagingu, dopiero potem produkcja. Przy takim procesie ryzyko awarii jest minimalne, a kopia zapasowa daje pełny powrót.

Jaką wersję PHP wybrać dla WordPressa w 2026?

PHP 8.3 albo 8.4. Obie są w pełni wspierane przez WordPressa i popularne wtyczki. 8.4 ma wsparcie do końca 2028 roku — to wybór długoterminowy. Wersje 7.4, 8.0 i 8.1 są po EOL i nie powinny być używane produkcyjnie; 8.2 kończy wsparcie 31 grudnia 2026.

Co zrobić, gdy po aktualizacji PHP strona pokazuje białą stronę?

Włącz WP_DEBUG w wp-config.php i sprawdź wp-content/debug.log — znajdziesz plik i linię błędu. Najczęściej winna jest stara wtyczka albo snippet w motywie. Tymczasowo wyłącz wtyczki (zmiana nazwy katalogu wp-content/plugins), przywróć dostęp do panelu, a potem włączaj wtyczki pojedynczo. Jeśli błąd jest krytyczny — przywróć kopię i przełącz PHP z powrotem, potem diagnozuj na stagingu.

Czy muszę aktualizować wtyczki przed zmianą PHP?

Tak — to najważniejszy krok. Wtyczka w aktualnej wersji zwykle deklaruje zgodność z PHP 8.x; wtyczka sprzed dwóch lat — nie. Kolejność jest celowa: aktualizacje na starym PHP (gdzie możesz zdiagnozować ewentualne problemy), potem zmiana wersji. Odwrotna kolejność łączy dwa źródła ryzyka w jednym momencie.

Czy aktualizacja PHP przyspieszy moją stronę WordPress?

Zwykle tak — nowsze wersje PHP są szybsze, a strony WordPress z rozbudowanym ekosystemem wtyczek zyskują szczególnie na optymalizacjach silnika. Realny zysk zależy od hostingu, cache i wtyczek. Po aktualizacji wyczyść wszystkie warstwy cache (wtyczka, OPcache, CDN) i zmierz wynik w PageSpeed Insights — porównanie przed/po da konkretne liczby.

Czy mogę cofnąć aktualizację PHP, jeśli coś pójdzie nie tak?

Tak — powrót to przełączenie wersji PHP z powrotem w panelu hostingu, zwykle w minutę. Dlatego stara wersja zostaje na serwerze do czasu potwierdzenia stabilności. Jeśli problemy pojawią się po stronie kodu (nie środowiska), cofasz też wtyczki do poprzednich wersji — dlatego przed aktualizacjami warto zapisać ich wersje (albo mieć pełną kopię).

Źródła

• WordPress — wymagania i wspierane wersje PHP
• WordPress — aktualizacja PHP (oficjalny poradnik)
• PHP.net — wspierane wersje
• WordPress — Zdrowie witryny (informacje o serwerze)

📖 Zobacz również: staging WordPress.