Kto właściwie aktualizuje PHP w WordPressie i dlaczego nie zrobi tego za Ciebie

WordPress nie ma dostępu do wersji interpretera PHP na serwerze i nie może jej zmienić. Gdy w Narzędzia → Kondycja witryny pojawia się komunikat „Twoja witryna działa na nieaktualnej wersji PHP”, to nie jest błąd WordPressa, a wyłącznie sygnał: gałąź ustawiona dla Twojego konta kończy wsparcie. Samą zmianę wykonuje hosting albo osoba administrująca serwerem.

W praktyce wersję PHP ustawia się w jednym z pięciu miejsc:

• cPanel → MultiPHP Manager — wybór gałęzi dla domeny i przycisk „Apply”.
• DirectAdmin → Extra Features → Select PHP Version.
• CloudPanel → Sites → wybrana domena → PHP Version.
• pliku .htaccess — dyrektywy typu AddHandler application/x-httpd-php82 .php; działa tylko na części hostingów.
• konfiguracji LiteSpeed, puli php-fpm w nginx albo obrazie Dockera (np. php:8.2-fpm) — tu zmiana idzie przez plik konfiguracyjny i restart usługi.

Aktualizacja WordPressa (rdzeń, wtyczki, motyw) to zupełnie inny proces. Możesz mieć WordPressa 6.7 na PHP 7.4 i strona będzie działać — do dnia, w którym hosting wyłączy starą gałąź. Przy hostingu współdzielonym za aktualizacje PHP odpowiada dostawca: ustawia wersję domyślną i wysyła komunikat o wyłączeniu starej, zwykle 30–90 dni wcześniej. Twój zakres to wybór wersji z listy i sprawdzenie, czy sklep nadal działa. Na VPS-ie lub serwerze dedykowanym odpowiedzialność przechodzi na Ciebie albo na firmę administrującą serwerem — razem z aktualizacją pakietów, konfiguracji i restartem usług. Jeśli nie chcesz tego pilnować we własnym zakresie, zobacz, co obejmuje opieka WordPress Białystok i ile kosztuje.

Konsekwencja pominięcia tematu jest jedna i twarda: gałąź po zakończeniu wsparcia nie dostaje łatek bezpieczeństwa, a publicznie znane luki w PHP są skanowane i wykorzystywane automatycznie.

Jaką wersję PHP wybrać: mapa wsparcia, EOL i zgodność

Punktem startowym jest oficjalny cykl życia PHP. Poniżej stan na moment publikacji — daty się zmieniają, więc przed decyzją zweryfikuj je na php.net (php.net/supported-versions.php) i sprawdź, co domyślnie oferuje Twój hosting.

Rekomendacja praktyczna: celuj w jedną z gałęzi w aktywnym wsparciu, ale nie w najświeższą premierę. Nowa wersja PHP pojawia się w produkcji u dostawców zwykle kilka miesięcy po wydaniu, a wtyczki nadrabiają zgodność jeszcze później. Bezpieczniejszy ruch to wybór o jedną–dwie wersje wstecz od najnowszej, po audycie wtyczek. Nie przeskakuj z PHP 7.4 od razu na 8.4 na produkcji — to niepotrzebne ryzyko, bo dwie duże zmiany łamiące zgodność nakładają się na siebie.

Po stronie platformy: WordPress 6.x wspiera PHP od 7.2.24, ale sam zespół rekomenduje 7.4 lub nowszą gałąź, a bieżące wydania są testowane na PHP 8.x — aktualne wymagania znajdziesz na wordpress.org/about/requirements. WooCommerce ma własne, nieco węższe wymagania, opisane w dokumentacji WooCommerce. PrestaShop rozdziela gałęzie: 1.7 obsługuje PHP 7.x, a linia 8.x wymaga PHP 8 — dokładne zakresy dla konkretnej wersji sprawdź w dokumentacji dla deweloperów PrestaShop. Zawsze porównaj trzy rzeczy: wymagania platformy, wymagania wtyczek/modułów i to, co realnie udostępnia hosting. Jeśli któraś wtyczka deklaruje „Requires PHP: 7.4”, przy PHP 8.3 nadal musi być przetestowana — deklaracja to minimum, nie gwarancja.

Audyt przed aktualizacją: wtyczki, motyw i własny kod

Audyt ma odpowiedzieć na jedno pytanie: co się zepsuje, gdy zmienimy wersję PHP. Trzy najczęstsze źródła awarii to porzucone wtyczki, stary motyw i własny kod w child theme.

Wtyczki. W pliku głównym i w readme.txt szukaj nagłówka „Requires PHP” oraz pola „Tested up to”. Uwaga: „Tested up to” dotyczy WordPressa, nie PHP — wtyczka zgodna z WP 6.7 może jednocześnie wywalać fatal error na PHP 8. Listę aktywnych wtyczek z wersjami wyciągniesz przez WP-CLI: wp plugin list --status=active --fields=name,version,update. Weryfikacja po stronie hostingu to jedno polecenie: wp --info pokaże wersję PHP, na której pracuje CLI (może różnić się od tej używanej przez php-fpm).

Porzucone wtyczki. Brak aktualizacji dłużej niż 12 miesięcy to nasza najczęstsza przyczyna awarii przy przejściu na PHP 8.x. Typowe wywołania: create_function() (usunięte w PHP 8.0), each(), money_format(), składnia indeksu stringu w nawiasach klamrowych $t{0}, przekazywanie null do parametrów nie-nullowalnych (deprecated w 8.1) oraz dynamiczne właściwości klas (deprecated w 8.2).

Własny kod. functions.php w child theme, snippety wklejone z tutoriali i kod pisany pod PHP 7.x to zwykle najtrudniejszy element, bo nikt go nie aktualizuje automatycznie.

Narzędzia. PHP Compatibility Checker przeanalizuje wtyczki i motyw pod wybrany zakres wersji. Query Monitor pokaże błędy PHP, wolne zapytania i hooki na staging. Do tego WP_DEBUG i WP_DEBUG_LOG w wp-config.php oraz log błędów php-fpm. Wynik audytu zapisz jako listę: do naprawy, do wymiany, zostaje bez zmian. Jeśli połowa wtyczek wypada z listy, policz koszt wymiany — punkt odniesienia masz w zestawieniu ile kosztuje sklep internetowy WordPress.

Kopia zapasowa i staging — przygotowanie, którego nie wolno pominąć

Zanim ruszy jakakolwiek zmiana wersji PHP, na serwerze musi istnieć punkt powrotu. Backup robimy w dwóch częściach: pliki i baza danych. Przez SSH wygląda to tak: wp db export kopia-2026-01-15.sql oraz tar -czf pliki.tar.gz public_html. Kopia musi trafić poza serwer — na dysk lokalny, do Backblaze B2, S3 albo na Google Drive. Backup trzymany na tym samym hostingu nie ratuje, gdy padnie konfiguracja PHP-FPM albo nadpiszesz .htaccess i strona przestanie odpowiadać.

Środowisko testowe stawiasz na trzy sposoby:

• Subdomena (staging.twojadomena.pl) z osobną bazą danych na tym samym hostingu — najszybsze i najtańsze rozwiązanie.
• Klon z wtyczki — Duplicator, WPvivid, All-in-One WP Migration. Wygodne, ale przy sklepie z kilkoma GB w wp-content/uploads proces potrafi trwać godzinami i urywać się w połowie.
• Ręcznie: wp db export, import na staging, podmiana adresów przez wp search-replace 'https://twojadomena.pl' 'https://staging.twojadomena.pl', potem wp cache flush i czyszczenie cache obiektowego.

Trzy rzeczy, które są pomijane najczęściej:

• Wersja PHP na stagingu ma być identyczna z docelową na produkcji. Testy na 8.1, gdy produkcja pójdzie na 8.3, nic nie wnoszą.
• Wyłącz wysyłkę maili — wtyczka Disable Emails albo SMTP z przekierowaniem całego ruchu na jedną skrzynkę testową. Inaczej staging wyśle maile do prawdziwych klientów.
• Bramkę płatności przełącz na sandbox albo wyłącz. Crony zatrzymaj: wp cron event list, a następnie DISABLE_WP_CRON w wp-config.php — sklonowana baza potrafi przy pierwszym wejściu odpalić masowo zaległe zadania i wystrzelić serię maili.

Zapisz stan wyjściowy, do którego wracasz: wersję PHP (php -v), listę rozszerzeń (php -m oraz wynik phpinfo()), wersję MySQL/MariaDB (SELECT VERSION();) i konfigurację OPcache (memory_consumption, max_accelerated_files). Bez tego punktu powrotu przy błędzie 500 zostaje zgadywanie. Jeśli nie chcesz robić tego samodzielnie, opieka WordPress Białystok: co obejmuje i ile kosztuje opisuje, co wchodzi w taki pakiet.

Aktualizacja krok po kroku: cztery warianty zmiany wersji PHP

Sposób zmiany zależy od tego, jak zarządzasz serwerem. Poniżej cztery realne scenariusze.

Wariant 1: panel hostingu. Najczęstszy przypadek w małych i średnich firmach. W DirectAdmin szukaj sekcji Extra Features → Select PHP Version, w cPanel — Software → MultiPHP Manager, a limity ustawisz w MultiPHP INI Editor. Większość polskich hostingów ma własny panel z zakładką „PHP” przy domenie. Uwaga: ustawienie zwykle dotyczy konkretnej domeny lub katalogu, nie całego konta — po zmianie potwierdź w Narzędzia → Site Health albo w pliku z phpinfo(), że działa właściwa wersja.

Wariant 2: WP-CLI na stagingu. Kolejność ma znaczenie: najpierw wp plugin update --all i wp core update (plus wp core update-db) na starej wersji PHP, potem testy, dopiero na końcu zmiana PHP. Wyjątek: jeśli któraś wtyczka wymaga już nowszej gałęzi, aktualizacja na starym PHP się nie wykona — wtedy zmieniasz PHP na stagingu i szukasz konfliktów.

Wariant 3: pliki konfiguracyjne. W .htaccess działa AddHandler application/x-httpd-php83 .php (składnia bywa różna, czasem AddType), w Apache — SetHandler proxy:unix:/run/php/php8.3-fpm.sock, w php-fpm pool w /etc/php/8.3/fpm/pool.d/, na LiteSpeed — LSAPI. Główne ryzyko: hosting przy własnej aktualizacji potrafi nadpisać .htaccess. Trzymaj kopię i sprawdzaj plik po każdej zmianie po stronie dostawcy.

Wariant 4: Docker. Dla firm z własnym środowiskiem deweloperskim — obraz php:8.3-fpm w docker-compose razem z bazą, wersja zapisana w repozytorium, więc cały zespół pracuje na tym samym.

Zasada wdrożenia jest jedna: staging → testy → produkcja w oknie o niskim ruchu (np. 2:00–4:00), z zapisaną godziną zmiany i osobą, która ją wykonała.

Testy po aktualizacji: co sprawdzić w pierwszych 30 minutach

„Strona się otwiera” to nie test. Pierwsze pół godziny po zmianie PHP to konkretna lista punktów, wykonywana na produkcji zaraz po wdrożeniu.

Front i panel: zaloguj się do /wp-admin, zapisz wpis, wgraj plik do biblioteki mediów (najlepiej plik JPEG i PDF), zapisz ustawienia w Ustawienia → Bezpośrednie odnośniki, wyślij formularz kontaktowy i sprawdź, czy mail doszedł.

Ścieżka zakupowa: dodaj produkt do koszyka, przejdź checkout, wykonaj jedną transakcję testową przez bramkę w trybie produkcyjnym na kwotę 1 zł i zwróć ją — to jedyny sposób, żeby sprawdzić, czy webhook bramki zwraca poprawny status. Osobno przetestuj wybór paczkomatu InPost oraz kuriera DPD i DHL: mapy działają na JavaScript, więc problem widać od razu.

Integracje: ERP i magazyn (czy stan schodzi po zmianie statusu zamówienia), feedy Ceneo i Google Merchant, płatności cykliczne, REST API — curl https://twojadomena.pl/wp-json/wp/v2/posts, webhooki do systemów zewnętrznych.

Diagnostyka: w wp-config.php ustaw WP_DEBUG i WP_DEBUG_LOG na true, a WP_DEBUG_DISPLAY na false. Sprawdź wp-content/debug.log, error_log PHP oraz log serwera (Apache, Nginx, LiteSpeed). Po testach wyłącz debugowanie — publiczne komunikaty błędów to wyciek informacji o serwerze.

Wydajność: zmierz TTFB przed i po zmianie: curl -o /dev/null -s -w '%{time_starttransfer}\n' https://twojadomena.pl — raz z wyłączonym cache, raz z włączonym. Bez rozdzielenia tych dwóch pomiarów przypiszesz efekt cache do zmiany PHP. Kontekst metryk wydajności opisuje dokumentacja Core Web Vitals. Przy sklepie prowadzonym przez kilka osób warto wcześniej ustalić, kto odpowiada za testy — organizacja pracy przy sklepie internetowym to temat równie praktyczny jak sama migracja.

Najczęstsze błędy po aktualizacji PHP i jak je naprawić

Po przełączeniu PHP na 8.1, 8.2 albo 8.3 rzadko pada cały sklep — zwykle pada jedna wtyczka. Dlatego pierwszy ruch to nie czytanie kodu, a ustalenie, co dokładnie się wywala.

Fatal error z treścią „Call to undefined function” albo „Call to a member function on null” oznacza kod napisany pod PHP 7.x. Włącz w wp-config.php stałe WP_DEBUG na true, WP_DEBUG_LOG na true, a WP_DEBUG_DISPLAY na false — wtedy ślad leci do wp-content/debug.log, a nie na ekran klienta. W logu szukasz pełnej ścieżki pliku: nazwa katalogu zaraz pod wp-content/plugins/ to winowajca. Drugi sposób na sklep z 30 wtyczkami: zmień nazwę katalogu wp-content/plugins na plugins_off (WordPress zdjąć wszystkie moduły naraz), a potem przywracaj je partiami po 5–8 i sprawdzaj, czy błąd wraca.

• Biały ekran i 500 — zanim zaczniesz szukać w kodzie: zajrzyj do error_log na poziomie hostingu (log WordPressa bywa pusty, jeśli błąd łapie FPM), sprawdź memory_limit (256M to dziś minimum przy Elementorze i WooCommerce) oraz max_execution_time. Część białych ekranów to nie błąd PHP, a stary handler w panelu hostingu.
• Deprecated i Warningi zalewające log — kosmetyczne są wtedy, gdy dotyczą funkcji wywoływanych raz na dobę w cronie. Jeśli lecą na każde żądanie w koszyku, checkoucie albo na liście produktów, to zwiastun awarii przy kolejnej wersji.
• REST API i blok edytora — gdy /wp-json/ zwraca 500, a edytor nie chce się załadować, to prawie zawsze stara wtyczka na PHP 8.x. Nazwę widać w logu; wyłącz ją i sprawdź, czy endpoint wraca.

Co realnie zyskujesz: wydajność, bezpieczeństwo i SEO

Największy zysk z nowszej gałęzi PHP nie siedzi w samych pętlach, tylko w OPcache. Skompilowany kod leży w pamięci zamiast być kompilowany przy każdym żądaniu: opcache.enable=1, opcache.memory_consumption=256, opcache.max_accelerated_files=20000. Uwaga na pułapkę — jeśli max_accelerated_files zostanie za nisko, cache się przesypuje i strona bywa wolniejsza niż przed migracją. JIT (opcache.jit=1255) pomaga w kodzie liczącym, ale sklep najczęściej czeka na MySQL. Przy 40 zapytaniach do bazy na kategorię różnica między PHP 7.4 a 8.2 w TTFB bywa w granicach szumu — dlatego najpierw sprawdź log wolnych zapytań, dopiero potem chwal się benchmarkiem.

Bezpieczeństwo to nie straszak, a kwestia harmonogramu: PHP 7.4 nie dostaje poprawek bezpieczeństwa od końca 2022 roku, więc podatność znaleziona w interpreterze zostaje otwarta na zawsze. Do tego konfiguracja: expose_php=Off (nie zdradzaj wersji w nagłówkach), display_errors=Off, log_errors=On.

SEO odczujesz tylko wtedy, gdy migracja była nieudana — błędy 500 i wolne odpowiedzi serwera trafiają do robotów jak każdy inny request. Po zmianie wejdź w Search Console: raport „Indeksowanie stron” (sekcja Błędy serwera 5xx) oraz statystyki pobierania. Efekt oceniaj po 2–4 tygodniach, nie po dwóch dniach. O tym, jak przekłada się to na budżet wdrożenia i utrzymania, piszemy w tekście o tym, ile kosztuje sklep internetowy WordPress, a jeśli chcesz mieć to pilnowane po starcie — sprawdź zakres stałej opieki WordPress i SLA. Szybkość ładowania jako sygnał jakości opisuje też dokumentacja Google o Core Web Vitals.

Najczęstsze błędy i jak je wykryć

Lista kontrolna do odklikania

• Sprawdź obecną wersję PHP — Zdrowie witryny → Informacje → Serwer albo panel hostingu. Zapisz wynik z datą.
• Ustal, kto zarządza serwerem — Hosting współdzielony — support dostawcy. VPS lub serwer dedykowany — Ty albo Twój administrator. Od tego zależy, kto zmienia wersję.
• Zapytaj hosting o politykę wersji PHP — Które wersje są dostępne, do kiedy wspierane i czy planowana jest wymuszona migracja.
• Zapisz punkt powrotu — Wersja PHP, lista rozszerzeń (php -m, phpinfo), wersja bazy danych i konfiguracja OPcache — zanim cokolwiek zmienisz.
• Sprawdź wymagania wtyczek — Nagłówek Requires PHP w pliku głównym wtyczki oraz pole Tested up to. Szybciej przez WP-CLI: wp plugin list.
• Wypisz wtyczki bez aktualizacji od ponad 12 miesięcy — Data ostatniego wydania w repozytorium lub na liście wtyczek. Każda taka pozycja to kandydat do wymiany.
• Przejrzyj child theme i własne snippety — functions.php, kod z tutoriali sprzed lat. Szukaj dynamicznych właściwości i niejawnych konwersji typowych dla PHP 7.x.
• Uruchom PHP Compatibility Checker — Na stagingu lub na kopii, z ustawioną docelową wersją PHP. Traktuj wynik jako listę zadań, nie wyrok.
• Zrób pełny backup plików i bazy poza serwerem — Termin: bezpośrednio przed jakąkolwiek zmianą konfiguracji PHP.
• Postaw staging na tej samej wersji PHP co produkcja — Subdomena, klon wtyczką albo wp db export/import. Środowiska muszą się zgadzać, inaczej test nie ma sensu.
• Wyłącz maile i realne płatności na stagingu — Termin: przed pierwszym testem koszyka. Inaczej testy wygenerują prawdziwe zamówienia i wyślemy klientom fałszywe potwierdzenia.
• Przetestuj ścieżkę zakupową i formularze — Koszyk, zamówienie, płatność w trybie testowym, formularz kontaktowy, logowanie do panelu.
• Po zmianie na produkcji obserwuj logi błędów — Pierwsze 24–48 godzin. Włącz podgląd logu na poziomie hostingu, nie tylko w WordPressie.
• Zapisz wniosek z audytu jako listę modułów — Każda pozycja: naprawa albo wymiana. Ta lista steruje kolejnością prac i budżetem.

Najczęściej zadawane pytania

Źródła i materiały

• Google Search Central – tworzenie treści dla ludzi
• Google Search Central – dane strukturalne
• Google Search Central – Core Web Vitals
• PrestaShop – dokumentacja dla deweloperów
• WooCommerce – dokumentacja