Czy aktualizacja PHP z 7.2 do 8.3 jest możliwa?

Jest możliwa i trzeba ją zrobić. Nie „warto rozważyć", tylko trzeba, i to bez odkładania na później. PHP 7.2 nie dostaje poprawek bezpieczeństwa od 30 listopada 2020 roku — każda luka znaleziona po tej dacie została w nim otwarta na stałe. To prawda, że taki skok potrafi rozsypać stronę i że nikt uczciwy nie obieca inaczej. Ale alternatywą jest strona, która sama zgłasza się botom skanującym internet, a prędzej czy później i tak przestanie działać, bo hosting wyłączy starą wersję.

Krótka odpowiedź: tak, ale nie na żywej stronie

Techniczne przeskoczenie z 7.2 na 8.3 to w panelu hostingu jedno kliknięcie. Problem polega na tym, co się stanie w sekundę po nim.

Między tymi wersjami jest sześć wydań języka. W tym czasie usunięto funkcje, których używały starsze wtyczki, a spora część rzeczy, które kiedyś kończyły się ostrzeżeniem w logu, kończy się teraz błędem krytycznym i białym ekranem. Strona zbudowana w 2019 roku i nietknięta od tamtej pory ma realną szansę nie wstać.

Ryzyko nie polega na tym, że coś pęknie. Polega na tym, że pęknie w chwili, gdy nie masz kopii i nie wiesz, jak się cofnąć.

Dlatego cała robota sprowadza się do jednego: zrobić to w kontrolowanych warunkach, z pełną kopią plików i bazy, najlepiej najpierw na klonie strony. Wtedy najgorszy scenariusz brzmi „wracamy do punktu wyjścia i planujemy inaczej", a nie „sklep nie działa trzeci dzień".

Sprawdź, ile lat Twoja wersja jest bez poprawek

Wersję PHP znajdziesz w panelu hostingu albo w WordPressie w Narzędzia → Stan witryny → Informacje → Serwer. Kliknij ją poniżej.

Daty zakończenia wsparcia pochodzą z oficjalnego harmonogramu wydań PHP. Liczba miesięcy liczona względem sierpnia 2026. Przed wdrożeniem warto potwierdzić aktualny harmonogram na php.net, bo terminy bywają przesuwane.

Osiem zagrożeń, które niesie PHP 7.2

1. Otwarte luki bez łatek

   Od listopada 2020 nie powstała żadna poprawka bezpieczeństwa. Podatności wykryte później są opisane publicznie i nigdy nie zostaną w tej wersji naprawione.

2. Automatyczne skanowanie przez boty

   Wykrycie wersji PHP zajmuje sekundy i robią to programy przeczesujące internet bez udziału człowieka. Nie trzeba być znaną firmą, żeby zostać znalezionym.

3. Wtyczki i motywy przestają być wspierane

   Autorzy porzucają stare wersje języka. Utykasz na wtyczkach sprzed lat, które same w sobie mają nienaprawione luki, bo nowszych nie da się na tym uruchomić.

4. Blokada aktualizacji WordPressa

   Kolejne wydania rdzenia podnoszą wymagania. Zostajesz ze starym WordPressem, a to drugi zestaw otwartych podatności obok tego w PHP.

5. Wyłączenie wersji przez hosting

   Dostawcy usuwają przestarzałe wersje z serwerów. Przychodzi mail o przełączeniu w konkretnym dniu i strona pada w terminie wybranym przez kogoś innego niż Ty.

6. Wolniejsze działanie

   PHP 8 jest zauważalnie szybszy od 7.2 przy tym samym kodzie. Wolniejszy serwer to gorsze wyniki Core Web Vitals, a te wchodzą do oceny strony w wyszukiwarce.

7. Ryzyko dla danych klientów

   Formularze kontaktowe, zamówienia i konta użytkowników leżą na oprogramowaniu bez poprawek. Artykuł 32 RODO wymaga odpowiednich środków technicznych — niezałatany serwer trudno za taki uznać.

8. Utrata widoczności po włamaniu

   Zainfekowana strona zaczyna serwować cudze treści i wypada z wyników wyszukiwania. Odzyskanie pozycji po takim zdarzeniu trwa znacznie dłużej niż sama naprawa.

„Nic nie ruszaliśmy od sześciu lat" to argument za, nie przeciw

Najczęstsza reakcja brzmi: skoro działa, po co ruszać. Rozumiem ją i uważam za zrozumiałą, tylko odwraca ona logikę.

Strona nietknięta od sześciu lat nie jest stabilna. Jest zamrożona. Przez ten czas opublikowano setki poprawek bezpieczeństwa, których nie dostała, i każda kolejna wykryta luka powiększa dystans. To, że dziś się otwiera, mówi tyle, że jeszcze nikt jej nie zaatakował albo że atak jeszcze nie jest widoczny.

Im dłuższa zwłoka, tym większa robota. Aktualizacja z 7.2 od razu na 8.3 jest trudniejsza niż seria mniejszych kroków rozłożonych na lata — ale to argument za zaczęciem teraz, nie za odkładaniem. Za rok będzie o jedno wydanie dalej.

Co konkretnie psuje się przy takim skoku

Żeby było jasne, skąd bierze się ryzyko, oto typowe przyczyny białego ekranu po przełączeniu.

Ostatnia kolumna jest sednem problemu z wyceną. Ta sama przyczyna w dwóch różnych serwisach potrafi oznaczać dwie godziny pracy albo dwa tygodnie.

Dlaczego prawie zawsze idzie to razem z WordPressem

PHP jest fundamentem, na którym stoi WordPress, wtyczki i motyw. Podniesienie samego fundamentu bez reszty budynku kończy się zwykle tym, że budynek nie pasuje.

Nowsze wersje PHP wymagają nowszych wtyczek. Nowsze wtyczki wymagają nowszego rdzenia WordPressa. Nowszy rdzeń bywa niezgodny ze starym motywem. To łańcuch, w którym pociągnięcie za jeden element rusza pozostałymi, dlatego w praktyce robi się to jednym podejściem, w ustalonej kolejności.

1. Kopia zapasowa

   Pliki i baza danych, pobrane również na dysk lokalny. Punkt powrotu przed jakąkolwiek zmianą.

2. Klon strony do testów

   Kopia na osobnym adresie, niewidoczna dla klientów i dla wyszukiwarki. Tu odbywa się całe ryzykowne przełączanie.

3. Rdzeń WordPressa i wtyczki

   Najpierw sam WordPress, potem wtyczki partiami, ze sprawdzeniem strony po każdej partii. Dzięki temu wiadomo, co konkretnie zawiniło.

4. Motyw

   Najbardziej wrażliwy element, bo odpowiada za wygląd. Sprawdzenie, czy aktualizacja nie nadpisze wcześniejszych przeróbek.

5. Przełączenie PHP

   Dopiero na końcu i dopiero na klonie. Przejście po podstronach, formularzach, koszyku i logowaniu, zanim cokolwiek trafi na żywą stronę.

6. Wdrożenie i obserwacja

   Powtórzenie sprawdzonej kolejności na produkcji, a potem kilka dni patrzenia w logi błędów.

Dlaczego wycena jest zawsze indywidualna

Tu muszę być bezwzględnie szczery, bo to najczęstsze źródło rozczarowań w tej branży.

Nie da się rzetelnie wycenić takiej aktualizacji przed obejrzeniem strony. Nie dlatego, że ktoś nie chce podać ceny, tylko dlatego, że przed testem nikt nie wie, co wyskoczy. Dwie strony wyglądające tak samo mogą mieć w środku zupełnie różny bałagan.

Realny rozrzut wygląda tak. Bywa, że po przełączeniu wszystko działa, a poprawki sprowadzają się do dwóch linijek w pliku motywu. Bywa też, że wtyczka, bez której strona nie działa, nie ma następcy, dane trzeba przenieść ręcznie, a pół szablonu wymaga przepisania. Obie sytuacje wychodzą z tego samego opisu na starcie: „strona firmowa na WordPressie, nieaktualizowana od kilku lat".

Dlatego kolejność jest taka: najpierw przegląd, potem test na klonie, dopiero potem wycena z ustalonym zakresem. Przegląd pokazuje wersje, listę wtyczek, motyw i własne przeróbki. Test pokazuje, co faktycznie pęka. Wycena wychodzi z tego, co widać, a nie z tego, co ktoś zgaduje przez telefon.

Skoro i tak skaczesz, to warto wiedzieć dokąd

To rzecz, o której rzadko się wspomina, a ma znaczenie dla portfela.

PHP 8.3 ma wsparcie bezpieczeństwa zaplanowane do końca 2027 roku. PHP 8.4 — do końca 2028. Skoro najtrudniejsza część roboty polega na doprowadzeniu wtyczek i motywu do zgodności z ósemką, to różnica między celem 8.3 a 8.4 jest zwykle niewielka, a kupuje dodatkowy rok spokoju.

Nie zawsze to wychodzi. Bywa, że jakaś wtyczka deklaruje zgodność do 8.3 i wtedy dalej się nie idzie. Ale warto zadać to pytanie na etapie testów, zamiast odkryć za rok, że trzeba powtarzać całą operację.

Zanim zadzwonisz do kogokolwiek

Trzy rzeczy, które warto sprawdzić samodzielnie i mieć pod ręką. Skracają rozmowę i pozwalają wstępnie ocenić skalę.

• Wersja PHP — WordPress, Narzędzia → Stan witryny → Informacje → Serwer.
• Wersja WordPressa i liczba wtyczek — Kokpit → Aktualizacje pokaże, ile jest zaległych.
• Skąd pochodzi motyw — z repozytorium WordPressa, z giełdy szablonów, czy robiony na zamówienie. To ma największy wpływ na koszt.

Warto też sprawdzić, czy hosting nie przysłał już zapowiedzi wyłączenia starej wersji. Jeśli tak, termin przestaje być Twoim wyborem. Przy okazji: wersja PHP należy do tych rzeczy, które ustawia się po stronie domeny i hostingu, a nie w samej stronie.

Częste pytania