Jak zaktualizować PHP na stronach WordPress klientów, nie psując ich

Wydanie bezpieczeństwa PHP z października 2026 było przydatnym przypomnieniem: niektóre poprawki nie przychodzą z aktualizacją WordPress. Gdy luka jest w samym PHP, poprawką jest nowsza wersja PHP na serwerze, a strony na gałęzi, która nie dostaje już poprawek bezpieczeństwa, nie dostają żadnej. Ten poradnik to procedura, którą możesz przeprowadzić na każdej stronie klienta, aby bez niespodzianek przenieść ją na wspieraną wersję PHP.

Dlaczego wersja PHP ma większe znaczenie, niż się wydaje

Każda gałąź PHP dostaje poprawki bezpieczeństwa przez ograniczony czas. Gdy przestaje je dostawać, każda nowa luka pozostaje otwarta, bez względu na to, jak starannie aktualizujesz WordPress, wtyczki i motywy. PHP 8.1 i starsze nie dostają już oficjalnych poprawek bezpieczeństwa. Sprawdź php.net/supported-versions , aby poznać aktualne daty dla każdej gałęzi.

Jest też drugi powód. Autorzy wtyczek i motywów z czasem przestają wspierać stare wersje PHP. Strona, która zostaje na starej gałęzi, powoli traci dostęp do aktualizacji wtyczek, a wraz z nimi do poprawek bezpieczeństwa w samych wtyczkach.

Krok 1: spisz wersję PHP każdej strony

W WordPress znajdziesz ją w Narzędzia → Kondycja witryny → Informacje → Serwer. Pokazuje ją też panel hostingu. Dla każdej strony zanotuj wersję PHP, wersję WordPress, motyw, kreator stron, czy działa WooCommerce i czy jest własny kod w motywie potomnym lub wtyczce must-use.

Potem posortuj listę. Zacznij od najstarszych wersji PHP, a wśród nich od stron, które zarabiają lub zbierają zapytania: sklepów, stron rezerwacji i stron z ważnymi formularzami.

Krok 2: znajdź to, co zablokuje przejście

Większość aktualizacji PHP rozbija się o jedną starą wtyczkę, porzucony motyw albo fragment własnego kodu. Poszukaj ich, zanim przełączysz:

• Wtyczki i motywy, które nie były aktualizowane od dwóch lat lub dłużej. Sprawdź wiersze „Requires PHP” i „Tested up to” na ich stronie wtyczki.
• Stare wersje kreatorów stron i wtyczek premium z wygasłą licencją, przez co strona nigdy nie dostała wersji wspierających nowsze PHP.
• Własny kod w functions.php lub wtyczkach must-use. Funkcje takie jak each() i create_function() usunięto w PHP 8.0, a PHP 8.2 ostrzega przed dynamicznymi właściwościami.
• Skanery zgodności mogą pomóc, ale zgłaszają fałszywe alarmy. Traktuj ich wynik jako listę startową, nie wyrok.

Najpierw zaktualizuj WordPress, wtyczki i motywy, póki strona działa jeszcze na obecnej wersji PHP. Nowsze wersje wtyczek zwykle wspierają nowsze PHP. Rób aktualizacje i zmianę PHP w różne dni, żeby wiedzieć, która zmiana spowodowała problem.

Krok 3: najpierw przetestuj na kopii

Zrób kopię stagingową strony i ustaw na niej docelową wersję PHP. U większości hostingodawców wersję PHP wybiera się dla każdej strony osobno. Włącz WP_DEBUG_LOG na kopii, żeby błędy trafiały do pliku logu, a nie na ekran.

Potem przeklikaj to, co ważne dla tego klienta:

• Stronę główną i dwie lub trzy najczęściej odwiedzane podstrony, na komputerze i telefonie.
• Każdy ważny formularz: wyślij go i sprawdź, czy e-mail dochodzi.
• W sklepie: dodanie do koszyka, kasa z zamówieniem testowym, strona konta.
• W panelu: edytor i kreator stron się otwierają, wgrywanie mediów działa, strony ustawień się ładują.

Potem przeczytaj wp-content/debug.log. Błędy krytyczne trzeba naprawić przed publikacją. Komunikaty o przestarzałych funkcjach to ostrzeżenia przed kolejną aktualizacją; zapisz je, mogą poczekać. Porównanie zrzutów ekranu kluczowych podstron przed i po wychwytuje problemy, które nie zgłaszają błędu, na przykład slider lub menu, które przestało się wyświetlać.

Krok 4: przełącz stronę produkcyjną w spokojnym momencie

Wybierz moment z małym ruchem. Tuż przed przełączeniem zrób świeżą kopię zapasową plików i bazy danych oraz zanotuj obecną wersję PHP. Zmień PHP w panelu hostingu, wyczyść pamięć podręczną stron i ewentualnie obiektów, a potem wykonaj te same sprawdzenia co na kopii. Zostaw zapisywanie błędów do pliku włączone na dzień lub dwa, żeby wychwycić podstronę, której nikt nie odwiedził podczas twojego sprawdzania.

Powiedz klientowi w jednym lub dwóch zdaniach, co zrobiłeś i dlaczego. Aktualizacja PHP jest niewidoczna, gdy wszystko idzie dobrze, a to dobra praca utrzymaniowa, o której powinien wiedzieć.

Krok 5: znaj drogę powrotu

Cofnięcie aktualizacji PHP jest zwykle proste: przełącz wersję z powrotem w panelu hostingu. Dlatego zanotowałeś starą wersję. Jeśli problemem okaże się jedna wtyczka, masz trzy opcje: zaktualizować ją, zastąpić albo przez krótki czas zostać na poprzedniej wspieranej gałęzi, póki tego nie rozwiążesz. Nigdy nie zostawaj na niewspieranej gałęzi dłużej, niż to konieczne.

Gdy jest pilnie: wydanie bezpieczeństwa samego PHP

Gdy zostanie opublikowana luka w PHP, aktualizacja WordPress jej nie naprawi. Zapytaj hostingodawcę, czy wydanie poprawkowe dla twojej gałęzi zostało wdrożone. Poprawka w obrębie tej samej gałęzi, na przykład z jednego wydania 8.3 na następne, rzadko coś psuje. Ryzykowny jest skok na nową gałąź i właśnie do tego przygotowuje cię ten poradnik. Strony na gałęzi bez poprawek bezpieczeństwa planujesz w pierwszej kolejności.

Aktualizacja z 23 października 2026: drugi problem PHP o niższym ryzyku. Dwa dni po krytycznym wydaniu PHP opublikował komunikat informacyjny o CVE-2026-115560 w session upload progress (php.net). PHP uważa wykorzystanie za mało prawdopodobne: wymaga ono jednocześnie kilku konkretnych ustawień i kodu. Poprawki jeszcze nie ma; pojawi się w następnym regularnym wydaniu PHP. Do tego czasu najpierw dokończ aktualizacje z 21 października, a potem poproś hostingodawcę o ustawienie session.upload_progress.enabled na off w php.ini lub w puli PHP-FPM i restart PHP. Ustawienie tego z poziomu WordPress lub pliku .user.ini może przy PHP-FPM zadziałać za późno.

Jak Verploy radzi sobie z aktualizacjami PHP

Na stronach ze starą wersją PHP kontrola aktualizacji PHP w Verploy pokazuje, co blokuje przejście i w jakiej kolejności to naprawić. Każda aktualizacja jest sprawdzana, a ryzykowne są najpierw testowane na kopii. Zobacz, jak to pasuje do pełnej procedury utrzymania, na stronie utrzymanie WordPress dla agencji.