Aktualizacja PHP i WordPressa: kolejność, koszt i ryzyko

Krótka odpowiedź: aktualizację PHP i WordPressa robi się w jednej, ustalonej kolejności: kopia zapasowa, kopia testowa, rdzeń, wtyczki, motyw, a wersja PHP na końcu, bo to ona ujawnia niezgodności w starym kodzie. Wersję PHP przełącza się w panelu hostingu, nie w panelu WordPressa. Jeżeli serwis stoi na PHP 8.1 lub starszym, nie dostaje już żadnych poprawek bezpieczeństwa i przejście jest pilne.

Ten tekst jest o jednej konkretnej operacji technicznej. Jeżeli szukasz szerszego obrazu, czyli co jeszcze wchodzi w skład prac na działającym serwisie i ile kosztują, właściwym adresem jest aktualizacja strony internetowej. Jeżeli natomiast interesuje Cię stały miesięczny pakiet zamiast pojedynczego zlecenia, opisaliśmy go osobno przy opiece nad stroną internetową.

Dlaczego wersja PHP jest ważniejsza niż numerek WordPressa

WordPress przypomina o swoich aktualizacjach sam, żółtym paskiem na górze panelu. PHP nie przypomina o niczym, bo jest warstwę niżej: to język, w którym napisany jest cały serwis, uruchamiany na serwerze. Dlatego właściciele firm dowiadują się o zbyt starym PHP zwykle przypadkiem, gdy jakaś wtyczka odmówi instalacji.

Twórcy PHP publikują harmonogram z góry i trzymają się go co do dnia. Każda gałąź dostaje dwa lata aktywnego rozwoju, potem jeszcze rok samych poprawek bezpieczeństwa, a następnie nie dostaje już nic. Poniżej stan na wrzesień 2026 roku.

Rdzeń WordPressa wymaga dziś co najmniej PHP 7.4, ale to jest minimum techniczne, przy którym system się uruchomi, a nie zalecenie. Uruchomi się także na serwerze, który od czterech lat nie dostał żadnej poprawki bezpieczeństwa. Różnica między "działa" a "jest bezpieczne" to dokładnie ta różnica.

Jak sprawdzić, na jakim PHP stoi Twoja strona

Są trzy drogi i wszystkie zajmują poniżej pięciu minut. Pierwsza: w panelu WordPressa wejdź w Narzędzia, a potem Stan witryny i zakładkę Informacje. W sekcji Serwer widnieje aktualna wersja PHP. Druga: panel hostingu ma zwykle osobną pozycję o nazwie Wersja PHP albo Ustawienia PHP, przypisaną do konkretnej domeny. Trzecia, gdy do panelu nie masz dostępu: poproś o to osobę, która płaci za hosting, bo to konto ma nad tym kontrolę.

Warto zapamiętać jedną rzecz, bo oszczędza sporo nerwów. Wersji PHP nie zmienia się w WordPressie. Zmienia się ją u firmy, która utrzymuje serwer, i tam też trzeba szukać przełącznika. To dlatego zapytania w wyszukiwarce mają tak często postać "aktualizacja PHP" z dopisaną nazwą dostawcy. Jeżeli w panelu Twojego dostawcy hostingu dla firm nie ma takiego przełącznika albo wsparcie nie potrafi powiedzieć, jakie wersje są dostępne, to sam w sobie jest sygnał, że warto rozejrzeć się za innym serwerem, bo za rok problem wróci.

Kolejność, która nie psuje strony

Aktualizacja WordPressa potrafi zepsuć serwis i zdarza się to regularnie. Nie dlatego, że oprogramowanie jest złej jakości, tylko dlatego, że typowa strona firmowa to rdzeń od jednego zespołu, motyw od drugiego i kilkanaście wtyczek od kilkunastu różnych autorów, z których każdy wydaje własne wersje we własnym rytmie. Kolejność ogranicza ryzyko lepiej niż ostrożność.

1. Pełna kopia zapasowa. Pliki i baza danych, pobrane poza serwer, opisane datą. Kopia leżąca na tym samym koncie hostingowym co strona nie jest kopią zapasową, tylko drugim egzemplarzem tego samego ryzyka.
2. Kopia testowa serwisu. Ten sam zestaw plików i baza pod adresem zamkniętym dla wyszukiwarek. Cała praca dzieje się tutaj, a nie na żywej stronie.
3. Rdzeń WordPressa. Najpierw system, bo wtyczki są pisane pod jego wersje, a nie odwrotnie.
4. Wtyczki, pojedynczo. Nie hurtem. Po każdej sprawdzasz stronę, bo tylko wtedy wiesz, która zepsuła.
5. Motyw. Jeżeli był modyfikowany bez motywu potomnego, aktualizacja skasuje zmiany. Sprawdź to zanim klikniesz, nie potem.
6. Wersja PHP. Na końcu, bo to ona ujawnia stary kod. Podnoś o jedną gałąź naraz i po każdej przejdź stronę.
7. Test ścieżek, które przynoszą pieniądze. Formularz kontaktowy razem z faktycznym dotarciem maila, koszyk, płatność, logowanie, wyszukiwarka, wersja mobilna.
8. Przeniesienie na produkcję w porze najmniejszego ruchu, z przygotowaną ścieżką powrotu i ponownym sprawdzeniem tych samych ścieżek.

Punkt siódmy jest tym, który najczęściej się pomija, a odpowiada za najdroższe niespodzianki. Strona po aktualizacji zwykle wygląda dobrze. Popsuta bywa wysyłka maili z formularza, czyli jedyna rzecz, na której właścicielowi naprawdę zależy, i o awarii dowiaduje się po dwóch tygodniach ciszy w skrzynce.

Jak zaktualizować WordPressa ręcznie

Ręczna aktualizacja przydaje się w dwóch sytuacjach: gdy automat kończy się błędem i zostawia stronę w trybie konserwacji albo gdy panel administracyjny w ogóle się nie otwiera. Kroki są zawsze te same. Robisz kopię plików i bazy. Pobierasz oficjalną paczkę WordPressa. Wyłączasz wtyczki, jeżeli masz jeszcze dostęp do panelu. Podmieniasz katalogi wp-admin oraz wp-includes na nowe, zostawiając nietknięty katalog wp-content, w którym siedzą Twoje motywy, wtyczki i pliki. Nadpisujesz pliki z katalogu głównego, poza wp-config.php. Wchodzisz na adres wp-admin i pozwalasz systemowi zaktualizować bazę danych. Na końcu włączasz wtyczki pojedynczo, sprawdzając stronę po każdej.

Jeżeli strona utknęła w trybie konserwacji, przyczyną jest zwykle plik o nazwie .maintenance w katalogu głównym, pozostawiony przez przerwaną aktualizację. Usunięcie go przywraca dostęp. To jedna z niewielu awarii WordPressa, którą da się naprawić w trzydzieści sekund.

Wtyczki: gdzie naprawdę leży ryzyko

Skala robi z WordPressa cel numer jeden. Według pomiaru W3Techs z 2 września 2026 roku napędza on 40,7 procent wszystkich stron w internecie, co daje 58,9 procent rynku systemów zarządzania treścią. Atakujący nie wybiera Twojej firmy. Wpisuje w skaner nazwę i wersję podatnej wtyczki, a potem przechodzi po wszystkim, co odpowiada, licząc na to, że ktoś nie zainstalował łatki opublikowanej pół roku temu.

Przy przeglądzie wtyczek patrzymy na cztery rzeczy, w tej kolejności. Data ostatniej aktualizacji: rozszerzenie nietknięte od dwóch lat traktujemy jak porzucone, nawet jeżeli nadal działa. Deklarowana zgodność z bieżącym WordPressem. Wygasłe licencje wtyczek płatnych, bo po wygaśnięciu przestają przychodzić aktualizacje, choć wtyczka nadal działa i nic o tym nie mówi. Oraz to, czy funkcja w ogóle jest jeszcze używana, bo najtańsza aktualizacja wtyczki to jej usunięcie. W typowym serwisie firmowym da się w ten sposób zdjąć kilka rozszerzeń, które kiedyś dodano do jednorazowego zadania.

Co robić, gdy po aktualizacji strona przestała działać

Najpierw sprawdź, czy widzisz stronę białą, czy z komunikatem błędu. Biała strona przy braku dostępu do panelu oznacza zwykle konflikt wtyczki albo motywu. Standardowa procedura: przez panel plików hostingu zmień nazwę katalogu wp-content/plugins na dowolną inną, na przykład plugins-off. To wyłącza wszystkie wtyczki naraz. Jeżeli strona wraca, przywracasz nazwę i włączasz rozszerzenia pojedynczo w panelu, aż znajdziesz winne. Jeżeli nie wraca, ta sama sztuczka z katalogiem motywu wskaże, czy problem jest tam.

Komunikat o błędzie krytycznym w PHP oznacza najczęściej, że kod motywu albo wtyczki używa czegoś, co w nowszej gałęzi zniknęło. Wtedy są trzy wyjścia: cofnąć wersję PHP w panelu hostingu i odzyskać czas, zaktualizować element blokujący, albo go wymienić. Pierwsze jest doraźne, bo termin końca wsparcia i tak nadejdzie. Trzecie bywa najtańsze, jeżeli chodzi o rozszerzenie porzucone przez autora.

Kiedy zlecić to komuś, a kiedy zrobić samodzielnie

Samodzielnie ma sens, gdy serwis był aktualizowany w ostatnim półroczu, stoi na PHP 8.2 lub nowszym, ma kilka popularnych wtyczek z aktywnym wsparciem i nie sprzedaje niczego bezpośrednio przez stronę. To jest praca na jedno spokojne popołudnie, pod warunkiem że zaczynasz od kopii zapasowej.

Zlecenie ma sens, gdy zachodzi którakolwiek z czterech rzeczy. Serwis nie był ruszany od kilku lat, więc trzeba przejść przez wersje pośrednie zamiast jednym skokiem. Strona sprzedaje, bo wtedy godzina przestoju kosztuje więcej niż cała usługa. Motyw był modyfikowany bez motywu potomnego, co znaczy, że aktualizacja skasuje pracę, za którą kiedyś zapłacono. Albo nie ma kopii zapasowej i nikt nie wie, kto ma dostęp do panelu hostingu, co samo w sobie jest osobnym problemem do rozwiązania przed jakąkolwiek aktualizacją.

Niezależnie od wyboru zapisz gdzieś datę i wersje przed oraz po. Brzmi to jak biurokracja, dopóki nie trzeba odpowiedzieć na pytanie, jakie środki bezpieczeństwa były wdrożone, i wtedy okazuje się jedynym dowodem, jaki firma ma pod ręką. Więcej o tym, dlaczego ten rejestr ma znaczenie także prawne, napisaliśmy przy aktualizacji strony internetowej, a o pozostałych warstwach zabezpieczeń przy tekście o tym, jak zabezpieczyć stronę internetową.