Pe scurt: Cel mai sigur dezactivați versiunile PHP vechi în trei faze: stabiliți utilizarea, blocați versiunea și observați, abia apoi dezinstalați. În Plesk, un handler poate fi mai întâi dezactivat, astfel încât să nu mai poată fi ales, și eliminat ulterior din Updates și Components. Fiecare versiune eliminată este una în minus pe care o aveți de patch-uit și repornit la următoarea vulnerabilitate, precum PHP2Shell.
De ce să faceți curat tocmai acum?
Săptămâna de după PHP2Shell le-a arătat multor administratori câte versiuni PHP sunt instalate pe serverele lor. Fiecare dintre ele a trebuit verificată, fiecare a avut nevoie de o actualizare sau de măsuri provizorii, fiecare serviciu de o repornire. Pentru PHP 8.1 și mai vechi există doar backporturi minime la nivel de sursă, iar pentru PHP 8.2 suportul se încheie pe 31.12.2026.
Cu această experiență proaspătă în memorie, este momentul potrivit pentru curățenie. Cum găsiți, în general, toate instalările descrie articolul Mai multe versiuni PHP pe un server. Aici este vorba despre pasul următor: dezactivarea controlată.
Faza 1: stabilirea utilizării
Înainte de a dezactiva ceva, trebuie să știți cine folosește o versiune. Site-urile sunt partea evidentă. Mai puțin vizibile sunt subdomeniile, instalările de test, cronjob-urile, scripturile și componentele panoului.
În Plesk, comanda plesk bin php_handler --list listează toți handlerii înregistrați. Cu --get-usage, Plesk arată, conform documentației, ce domenii folosesc un anumit handler. Niciuna dintre cele două comenzi nu modifică nimic.
# Plesk: toți handlerii și domeniile care folosesc un handler
plesk bin php_handler --list
plesk bin php_handler --get-usage -id <handler-id>
# General: cronjob-uri care apelează o anumită versiune PHP
grep -rE "php(7|8\.0|8\.1)" /etc/crontab /etc/cron.d /var/spool/cron 2>/dev/null
Verificați suplimentar logurile de acces ale site-urilor afectate: o instalare de test care nu a primit nicio cerere de luni de zile este un candidat la eliminare, nu la migrare. Notați pentru fiecare versiune veche cine o folosește și de ce.
Întrebați în plus oamenii care lucrează cu site-urile. Redacțiile, agențiile și departamentele de specialitate cunosc adesea procese care nu apar în nicio listă: exportul anual pentru contabilitate, formularul pentru un târg, interfața cu sistemul de gestiune a mărfurilor. Ceea ce depinde acolo de o versiune veche se observă altfel abia când lipsește.
Faza 2: blocarea și observarea
Pasul intermediar împiedică atribuirea nouă a unei versiuni, fără a o șterge imediat. În Plesk există posibilitatea de a dezactiva handleri individuali. Conform documentației Plesk, un handler dezactivat nu mai poate fi ales în setările PHP ale unui site; versiunea rămâne instalată. În linia de comandă se face cu plesk bin php_handler --disable -id <handler-id>.
Domeniile care mai folosesc versiunea veche le mutați în prealabil, în acord cu responsabilii, pe o versiune acceptată. Cum arată aceasta din perspectiva operatorului site-ului descrie articolul Schimbarea versiunii PHP în zona de clienți a hostingului. Alegerea handlerului potrivit o explică articolul Plesk: înțelegerea handlerilor PHP.
În perioada de observare urmăriți mesajele de eroare din loguri, rezultatele lipsă ale cronjob-urilor și reacțiile utilizatorilor. În alte panouri, funcțiile se numesc altfel; consultați acolo documentația producătorului.
Stabiliți sfârșitul perioadei de observare ca dată fixă și numiți cine aprobă dezinstalarea după aceea. Altfel, pasul intermediar devine o stare permanentă, iar versiunea veche rămâne totuși pe server.
Faza 3: dezinstalarea
Abia după ce perioada de observare a trecut fără evenimente, eliminați complet versiunea. În Plesk, conform documentației, aceasta se face la Tools & Settings, Updates, Add/Remove Components, în zona Web hosting, la versiunile interpretorului PHP. Versiunile instalate sunt marcate acolo și pot fi selectate pentru eliminare.
Pe serverele fără panou, gestionarul de pachete preia această sarcină. Salvați în prealabil configurația versiunii, de exemplu /etc/php/7.4/ pe Debian și Ubuntu, pentru a putea reconstitui în caz de urgență ce setări erau valabile.
# Salvarea configurației, apoi eliminarea pachetelor unei ramuri (exemplu Debian/Ubuntu, PHP 7.4)
tar czf /root/php74-konfiguration.tar.gz /etc/php/7.4/
apt remove 'php7.4*'
După eliminare merită un control. În Plesk, documentația recomandă plesk bin php_handler --reread pentru a reciti informațiile handlerilor după modificări ale binarelor PHP. Verificați în plus dacă planurile de servicii mai trimit la versiunea eliminată.
Obstacole tipice
| Obstacol | Cum îl recunoașteți | Ce ajută |
|---|---|---|
| O componentă a panoului depinde de versiune | Panoul raportează o dependență la eliminare | Mutați mai întâi componenta sau păstrați versiunea |
| Planul de servicii trimite la versiunea veche | Site-urile noi primesc versiunea veche sau un mesaj de eroare | Adaptați planul, apoi eliminați versiunea |
| Cronjob-ul apelează o cale fixă | Scriptul eșuează după eliminare | Schimbați calea către o versiune acceptată |
| Aplicația nu rulează pe versiunea nouă | Erori în logul de erori după mutare | Actualizați sau migrați aplicația |
Dacă o aplicație nu poate fi ridicată la o versiune acceptată, dezactivarea versiunii vechi nu mai este o chestiune de configurare, ci un proiect de migrare. Riscurile ramurilor depășite le descrie ghidul PHP End-of-Life: riscurile versiunilor depășite.
Următorul candidat este deja cunoscut
Curățenia nu este o acțiune unică. Încă pe 31.12.2026, PHP 8.2 iese din suportul proiectului PHP. Cine elimină acum versiunile până la 8.1 ar trebui să stabilească în același timp ce se întâmplă cu 8.2. Altfel, același joc începe din nou în câteva săptămâni.
O regulă simplă s-a dovedit utilă pentru server: se oferă doar ramuri pe care proiectul PHP le acceptă. Fiecare ramură primește la configurare o dată la care este verificată din nou, orientată după sfârșitul suportului de pe php.net. Contextul acestui ciclu îl explică pagina Versiunile PHP și ciclul de lansare.
Cine are clienți pe server ca furnizor de hosting sau agenție ar trebui să-i informeze din timp. Un anunț cu dată, rugămintea de mutare și o ofertă de sprijin evită ca site-urile să cedeze la data limită. Clienții a căror aplicație nu poate urma își dau astfel seama la timp că urmează o actualizare sau o migrare și pot planifica pentru ea.
Cum ajută PHP SOS concret?
- Stabilim ce site-uri, cronjob-uri și componente de panou folosesc ce versiune PHP.
- Mutăm domeniile, în acord cu dumneavoastră, pe versiuni acceptate și blocăm handlerii vechi.
- După perioada de observare eliminăm versiunile vechi controlat și verificăm rezultatul.
- Acolo unde aplicațiile nu pot urma, planificăm migrarea de la PHP 8.1 și mai vechi.
Întrebări frecvente
De ce ar trebui să elimin versiunile PHP nefolosite?
Fiecare versiune instalată trebuie verificată, actualizată și repornită la fiecare vulnerabilitate. Ramurile vechi, precum PHP 8.1 și mai vechi, nu mai primesc actualizări de la proiectul PHP. Versiunile nefolosite aduc doar risc și efort.
Care este diferența dintre dezactivare și dezinstalare?
La dezactivare, versiunea rămâne instalată, dar nu mai poate fi aleasă din nou. La dezinstalare, ea este eliminată de pe server. Dezactivarea este pasul intermediar sigur pentru a vedea dacă lipsește ceva.
Poate eliminarea unei versiuni PHP să perturbe funcții ale panoului?
Da. Unele componente ale unui panou, de exemplu webmail sau instrumentele de administrare, depind de o anumită versiune PHP. Clarificați astfel de dependențe înainte de eliminare; panoul le semnalează de regulă.
Cât timp ar trebui să dureze perioada de observare?
Atât cât toate procesele regulate să fi rulat cel puțin o dată, deci și cronjob-urile și exporturile lunare. Stabiliți durata împreună cu departamentele de specialitate.