PHP 7.4 / 8.0 / 8.1 bez wsparcia – co zrobić, gdy hosting zmienia wersję PHP?

W skrócie: PHP 7.4, 8.0 i 8.1 nie dostają już aktualizacji bezpieczeństwa. Dlatego firmy hostingowe stopniowo wyłączają te wersje albo pobierają dopłatę za ich dalsze utrzymanie. Nie warto ignorować takiego maila. Proszę sprawdzić, na jakiej wersji działa strona, przetestować nowe PHP na kopii i przełączyć wersję dopiero wtedy, gdy tam wszystko działa.

Taki mail zwykle wygląda niepozornie i ginie gdzieś między fakturą a newsletterem. Kto go przeoczy, zauważa problem dopiero wtedy, gdy strona nagle jest biała albo formularz kontaktowy przestaje wysyłać zapytania. Da się tego uniknąć – z odpowiednim wyprzedzeniem i we właściwej kolejności.

Kiedy kończy się wsparcie dla PHP 7.4, 8.0 i 8.1?

Każda wersja PHP dostaje aktualizacje bezpieczeństwa tylko przez określony czas. Potem nowo odkryte luki nie są już łatane. Dla trzech wersji, które wciąż działają na wielu stronach:

• PHP 7.4: bez aktualizacji bezpieczeństwa od 28.11.2022
• PHP 8.0: bez aktualizacji bezpieczeństwa od 26.11.2023
• PHP 8.1: bez aktualizacji bezpieczeństwa od 31.12.2025

Wszystkie trzy są więc już bez oficjalnych poprawek bezpieczeństwa. Strona, która na nich działa, nie psuje się od razu – ale stoi na fundamencie, którego nikt już nie naprawia.

Co zwykle pisze firma hostingowa

W Niemczech takie maile przychodzą zwykle po niemiecku. Sformułowania są różne, ale treść to najczęściej jeden z trzech przypadków:

• Automatyczna zmiana: „Ab dem [Datum] stellen wir alle Websites mit PHP 7.4 automatisch auf eine aktuelle Version um.“ – czyli od podanej daty hosting sam przełączy stronę na nowszą wersję, niezależnie od tego, czy kod jest na to gotowy.
• Dalsze działanie za dopłatą: „Für veraltete PHP-Versionen berechnen wir ab [Datum] eine zusätzliche monatliche Gebühr.“ – za starą wersję trzeba będzie płacić co miesiąc. Wielu dostawców oferuje to jako przedłużone wsparcie. Koszty bardzo się różnią w zależności od firmy i taryfy, często są liczone za pakiet albo za każdą stronę.
• Informacja bez terminu: „Ihre Website nutzt eine veraltete PHP-Version. Bitte aktualisieren Sie zeitnah.“ – prośba o aktualizację w najbliższym czasie. To najłagodniejsza wersja i właśnie ta najczęściej zostaje odłożona na później.

Dopłata może mieć sens, żeby zyskać czas. Na dłuższą metę płacą Państwo jednak co miesiąc za wersję, której nie utrzymują już sami twórcy PHP. Prędzej czy później zmiana i tak będzie konieczna.

Co może się zepsuć przy zmianie

Zmiana w obrębie jednej serii, np. z 8.1 na 8.2, jest zwykle niegroźna. Skok z 7.4 na 8.x jest większy. Typowe przyczyny błędów:

• Usunięte funkcje: each() i create_function() nie istnieją od PHP 8.0. Jeszcze starszy kod używa czasem mysql_connect() – tych funkcji brakuje już od PHP 7.0.
• Ostrzejsze sprawdzanie typów: wiele wbudowanych funkcji od PHP 8.0 zgłasza błąd, gdy dostanie parametr złego typu. Przykład: count() wywołane na wartości, która nie jest tablicą.
• Stare wtyczki i motywy: w WordPressie, TYPO3 czy sklepach problem często nie leży w samym systemie, tylko w rozszerzeniu, które od lat nie miało aktualizacji.
• Nowe ostrzeżenia: od PHP 8.2 pojawiają się np. komunikaty o dynamicznych właściwościach („Creation of dynamic property … is deprecated“). Nie wyłączają strony, ale zapełniają log błędów.

Krok 1: sprawdzić stan obecny

Zanim cokolwiek Państwo zmienią, warto zrobić przegląd:

• Wersja PHP: widać ją w panelu klienta u hostingodawcy, zwykle osobno dla każdej domeny lub katalogu. W WordPressie także w „Narzędzia → Kondycja witryny → Informacje“ (po niemiecku „Werkzeuge → Website-Zustand → Bericht“).
• Wersja CMS: czy WordPress, TYPO3 albo system sklepu jest aktualny? Stare wersje często w ogóle nie obsługują nowego PHP.
• Rozszerzenia: jakie wtyczki, motywy i rozszerzenia są zainstalowane i kiedy były ostatnio aktualizowane?
• Własny kod: czy są części pisane na zamówienie, interfejsy do innych systemów albo indywidualny motyw? To zwykle najbardziej pracochłonna część.

Dla własnego kodu PHP istnieją narzędzia, które automatycznie szukają niezgodności, np. PHPCompatibility dla PHP_CodeSniffer. Znajdują dużo, ale nie wszystko. Prawdziwego testu nie zastąpią.

Krok 2: przygotować kopię testową

Proszę nie zmieniać wersji PHP od razu na żywej stronie. Najpierw kopia:

1. Pełna kopia zapasowa plików i bazy danych.
2. Kopia na subdomenie, np. test.twoja-domena.de, z osobną bazą danych.
3. Zabezpieczenie kopii przed odwiedzającymi i wyszukiwarkami, najlepiej hasłem.
4. W sklepach i formularzach przełączenie wysyłki maili i płatności w tryb testowy, żeby prawdziwi klienci nie dostawali wiadomości.

U większości firm hostingowych wersję PHP dla subdomeny można ustawić osobno. Dzięki temu test odbywa się w takich samych warunkach jak później na żywej stronie.

Krok 3: właściwa kolejność

1. Na kopii najpierw aktualizacja CMS, wtyczek i motywów – jeszcze na starej wersji PHP. Nowe wersje rozszerzeń są często już przygotowane na nowsze PHP.
2. Włączenie logowania błędów: log_errors włączone, display_errors wyłączone. W WordPressie WP_DEBUG i WP_DEBUG_LOG zapisują komunikaty w wp-content/debug.log.
3. Zmiana wersji PHP na kopii. Przy dużych skokach często idę etapami, żeby każdy błąd dało się jasno przypisać do konkretnej wersji.
4. Przetestowanie wszystkiego: strona główna, podstrony, formularz kontaktowy, logowanie, wyszukiwarka, koszyk i zamówienie, panel administracyjny, generowanie PDF, zadania cron.
5. Naprawa błędów i ponowne sprawdzenie logu, aż będzie w nim spokój.
6. Zmiana na żywej stronie: te same aktualizacje, potem przełączenie PHP – w porze, gdy ruch jest mały.
7. Obserwacja przez kilka dni: kontrola logu błędów, test formularzy, uwaga na sygnały od klientów.

Warto mieć drogę powrotu. Dopóki hosting oferuje jeszcze starą wersję, w razie problemu można w panelu cofnąć zmianę. Po wymuszonym przełączeniu często nie jest to już możliwe – to kolejny powód, żeby działać wcześniej.

Na jaką wersję przejść?

Najlepiej na wersję, która jest jeszcze aktywnie wspierana i którą oficjalnie obsługuje Państwa CMS oraz rozszerzenia. Jeśli się da, nie warto przeskakiwać tylko o jedną wersję. Nowsze wersje też mają datę końca wsparcia, a każda zmiana kosztuje czas. Im dalej teraz, tym dłużej spokój.

Typowe błędy

• Odkładanie maila do ostatniego dnia. Wtedy brakuje czasu na test.
• Przełączenie od razu na żywej stronie w nadziei, że jakoś pójdzie.
• Sprawdzenie tylko strony głównej. Błędy często wychodzą dopiero w formularzu, przy zamówieniu albo w nocnym zadaniu cron.
• Ukrywanie komunikatów błędów zamiast ich naprawiania. To tylko przesuwa problem do następnej aktualizacji.
• Płacenie dopłaty bez końca, bez planu przejścia na nowszą wersję.

Kiedy potrzebna jest pomoc

Aktualną stronę na WordPressie z regularnie aktualizowanymi wtyczkami wielu właścicieli przestawia samodzielnie. Trudniej jest przy kodzie pisanym na zamówienie, przy rozszerzeniach, których nikt już nie rozwija, albo gdy hosting już zmienił wersję i strona przestała działać.

Przeprowadzam zmianę na kopii testowej, naprawiam błędy i przełączam żywą stronę dopiero wtedy, gdy wszystko działa. Jak to wygląda przy zmianie wymuszonej przez hosting, opisuję na stronie zmiana PHP na hostingu. Jeśli kod wymaga większych poprawek pod nową wersję, przebieg i ceny znajdą Państwo na stronie aktualizacja PHP (od 690 €).