Krótko: Stare wersje PHP najbezpieczniej wyłączać w trzech fazach: ustalić użycie, zablokować wersję i obserwować, dopiero potem odinstalować. W Plesk handler można najpierw dezaktywować, tak aby nie dało się go wybrać, a później usunąć w sekcji aktualizacji i komponentów. Każda usunięta wersja to o jedną mniej, którą przy następnej luce w rodzaju PHP2Shell trzeba łatać i restartować.
Dlaczego porządkować właśnie teraz?
Tydzień po PHP2Shell pokazał wielu administratorom, ile wersji PHP jest zainstalowanych na ich serwerach. Każdą z nich trzeba było sprawdzić, każda wymagała aktualizacji lub środków przejściowych, każda usługa restartu. Dla PHP 8.1 i starszych istnieją tylko minimalne backporty w kodzie źródłowym, a dla PHP 8.2 wsparcie kończy się 31.12.2026.
Z tym doświadczeniem świeżo w pamięci to dobry moment na porządki. Jak w ogóle znaleźć wszystkie instalacje, opisuje artykuł Wiele wersji PHP na jednym serwerze. Tutaj chodzi o kolejny krok: kontrolowane wyłączanie.
Faza 1: ustalenie użycia
Zanim cokolwiek wyłączą Państwo, muszą wiedzieć, kto korzysta z danej wersji. Strony internetowe to część oczywista. Mniej widoczne są subdomeny, instalacje testowe, zadania cron, skrypty i komponenty panelu.
W Plesk polecenie plesk bin php_handler --list wyświetla wszystkie zarejestrowane handlery. Opcja --get-usage pokazuje według dokumentacji, które domeny używają określonego handlera. Oba polecenia niczego nie zmieniają.
# Plesk: wszystkie handlery i domeny, które używają danego handlera
plesk bin php_handler --list
plesk bin php_handler --get-usage -id <handler-id>
# Ogólnie: zadania cron wywołujące określoną wersję PHP
grep -rE "php(7|8\.0|8\.1)" /etc/crontab /etc/cron.d /var/spool/cron 2>/dev/null
Proszę dodatkowo sprawdzić logi dostępu danych stron: instalacja testowa, która od miesięcy nie otrzymała żadnego żądania, jest kandydatem do usunięcia, a nie do migracji. Dla każdej starej wersji proszę zanotować, kto z niej korzysta i dlaczego.
Proszę też zapytać osoby pracujące ze stronami. Redakcje, agencje i działy merytoryczne często znają procesy, których nie ma na żadnej liście: coroczny eksport dla księgowości, formularz na targi, interfejs do systemu gospodarki towarowej. To, co jest związane tam ze starą wersją, wychodzi na jaw dopiero, gdy zacznie brakować.
Faza 2: blokada i obserwacja
Krok pośredni zapobiega ponownemu przypisaniu wersji, nie usuwając jej od razu. W Plesk istnieje możliwość dezaktywacji poszczególnych handlerów. Według dokumentacji Plesk dezaktywowanego handlera nie można już wybrać w ustawieniach PHP strony; wersja pozostaje zainstalowana. W wierszu poleceń robi się to przez plesk bin php_handler --disable -id <handler-id>.
Domeny, które nadal używają starej wersji, proszę wcześniej w uzgodnieniu z odpowiedzialnymi osobami przestawić na wspierane wersje. Jak wygląda to z perspektywy operatora strony, opisuje artykuł Zmiana wersji PHP w panelu klienta hostingu. Wybór właściwego handlera wyjaśnia artykuł Plesk: zrozumieć handlery PHP.
W okresie obserwacji proszę zwracać uwagę na komunikaty o błędach w logach, brak wyników zadań cron i odpowiedzi użytkowników. W innych panelach funkcje nazywają się inaczej; tam proszę sprawdzić dokumentację producenta.
Proszę ustalić koniec okresu obserwacji jako termin i wskazać, kto po nim zatwierdzi odinstalowanie. W przeciwnym razie krok pośredni staje się stanem trwałym, a stara wersja i tak zostaje na serwerze.
Faza 3: odinstalowanie
Dopiero gdy okres obserwacji minie bez zastrzeżeń, usuwają Państwo wersję całkowicie. W Plesk odbywa się to według dokumentacji w Tools & Settings, Updates, Add/Remove Components, w sekcji Web hosting przy wersjach interpretera PHP. Zainstalowane wersje są tam zaznaczone i można je wybrać do usunięcia.
Na serwerach bez panelu zadanie to przejmuje zarządzanie pakietami. Proszę wcześniej zachować konfigurację wersji, na przykład /etc/php/7.4/ w Debianie i Ubuntu, aby w razie potrzeby móc ustalić, jakie ustawienia obowiązywały.
# Zabezpieczyć konfigurację, potem usunąć pakiety gałęzi (przykład Debian/Ubuntu, PHP 7.4)
tar czf /root/php74-konfiguration.tar.gz /etc/php/7.4/
apt remove 'php7.4*'
Po usunięciu warto przeprowadzić kontrolę. W Plesk dokumentacja zaleca plesk bin php_handler --reread, aby po zmianach w binariach PHP ponownie wczytać informacje o handlerach. Proszę też sprawdzić, czy plany usług nadal nie wskazują usuniętej wersji.
Typowe pułapki
| Pułapka | Po czym ją poznać | Co pomaga |
|---|---|---|
| Komponent panelu zależy od wersji | Panel zgłasza zależność przy usuwaniu | Najpierw przestawić komponent albo zachować wersję |
| Plan usługi wskazuje starą wersję | Nowe strony otrzymują starą wersję lub komunikat o błędzie | Dostosować plan, potem usunąć wersję |
| Zadanie cron wywołuje stałą ścieżkę | Skrypt po usunięciu kończy się błędem | Zmienić ścieżkę na wspieraną wersję |
| Aplikacja nie działa na nowej wersji | Błąd po przestawieniu w logu błędów | Zaktualizować lub zmigrować aplikację |
Jeśli aplikacji nie da się podnieść do wspieranej wersji, wyłączenie starej wersji przestaje być tematem konfiguracji, a staje się projektem migracji. Ryzyka przestarzałych gałęzi opisuje poradnik PHP End-of-Life: ryzyka przestarzałych wersji.
Kolejny kandydat jest już znany
Porządkowanie nie jest jednorazową akcją. Już 31.12.2026 PHP 8.2 wypada z wsparcia projektu PHP. Kto teraz usuwa wersje do 8.1, powinien przy okazji ustalić, co dalej z 8.2. W przeciwnym razie ta sama gra zacznie się od nowa za kilka tygodni.
Sprawdziła się prosta zasada dla serwera: oferowane są tylko gałęzie wspierane przez projekt PHP. Każda gałąź otrzymuje przy konfiguracji datę, kiedy zostanie sprawdzona ponownie, zgodnie z końcem wsparcia na php.net. Tło tego cyklu wyjaśnia strona Wersje PHP i cykl wydawniczy.
Kto jako dostawca hostingu lub agencja ma na serwerze klientów, powinien poinformować ich z wyprzedzeniem. Ogłoszenie z datą, prośba o przestawienie i oferta wsparcia pozwalają uniknąć sytuacji, w której w dniu granicznym strony przestają działać. Klienci, których aplikacja nie nadąża, w ten sposób wcześnie zauważają, że czeka ich aktualizacja lub migracja, i mogą ją zaplanować.
Jak konkretnie pomaga PHP SOS?
- Ustalamy, które strony, zadania cron i komponenty panelu korzystają z której wersji PHP.
- W uzgodnieniu przestawiamy domeny na wspierane wersje i blokujemy stare handlery.
- Po okresie obserwacji usuwamy stare wersje w sposób kontrolowany i sprawdzamy wynik.
- Tam, gdzie aplikacje nie nadążają, planujemy migrację z PHP 8.1 i starszych.
Częste pytania
Dlaczego powinienem usuwać nieużywane wersje PHP?
Każdą zainstalowaną wersję trzeba przy każdej luce sprawdzić, zaktualizować i zrestartować. Stare gałęzie, takie jak PHP 8.1 i starsze, nie otrzymują już aktualizacji od projektu PHP. Nieużywane wersje przynoszą tylko ryzyko i nakład pracy.
Jaka jest różnica między dezaktywacją a odinstalowaniem?
Przy dezaktywacji wersja pozostaje zainstalowana, ale nie można jej już ponownie wybrać. Przy odinstalowaniu jest usuwana z serwera. Dezaktywacja to bezpieczny krok pośredni, aby zobaczyć, czy czegoś nie brakuje.
Czy usunięcie wersji PHP może zakłócić funkcje panelu?
Tak. Niektóre komponenty panelu, na przykład poczta webowa lub narzędzia administracyjne, są związane z określoną wersją PHP. Takie zależności należy wyjaśnić przed usunięciem; panel zwykle na nie wskazuje.
Jak długo powinien trwać okres obserwacji?
Na tyle długo, aby wszystkie regularne procesy wykonały się co najmniej raz, a więc także miesięczne zadania cron i eksporty. Czas należy ustalić z działami merytorycznymi.