Kort sagt: Gamla PHP-versioner inaktiverar ni säkrast i tre faser: kartlägg användningen, spärra versionen och observera, avinstallera först därefter. I Plesk kan en handler först inaktiveras, så att den inte längre går att välja, och senare tas bort under Updates och Components. Varje borttagen version är en mindre som ni måste patcha och starta om vid nästa sårbarhet av typen PHP2Shell.
Varför städa just nu?
Veckan efter PHP2Shell visade för många administratörer hur många PHP-versioner som är installerade på deras servrar. Varje version måste kontrolleras, varje behövde en uppdatering eller övergångsåtgärder, varje tjänst en omstart. För PHP 8.1 och äldre finns bara minimala backports i källkoden, och för PHP 8.2 upphör supporten den 31 december 2026.
Med den erfarenheten färsk i minnet är det rätta ögonblicket att städa. Hur ni överhuvudtaget hittar alla installationer beskrivs i inlägget Flera PHP-versioner på en server. Här handlar det om nästa steg: den kontrollerade avstängningen.
Fas 1: Kartlägg användningen
Innan ni stänger av något måste ni veta vem som använder en version. Webbplatser är den uppenbara delen. Mindre synliga är subdomäner, testinstallationer, cronjobb, skript och panelkomponenter.
I Plesk listar kommandot plesk bin php_handler --list alla registrerade handlers. Med --get-usage visar Plesk enligt dokumentationen vilka domäner som använder en viss handler. Inget av kommandona ändrar något.
# Plesk: alla handlers och de domäner som använder en handler
plesk bin php_handler --list
plesk bin php_handler --get-usage -id <handler-id>
# Allmänt: cronjobb som anropar en viss PHP-version
grep -rE "php(7|8\.0|8\.1)" /etc/crontab /etc/cron.d /var/spool/cron 2>/dev/null
Granska dessutom åtkomstloggarna för de berörda webbplatserna: en testinstallation som inte har fått någon förfrågan på månader är en kandidat för borttagning, inte för migrering. Anteckna för varje gammal version vem som använder den och varför.
Fråga också dem som arbetar med webbplatserna. Redaktioner, byråer och fackavdelningar känner ofta till förlopp som inte står i någon lista: den årliga exporten till bokföringen, formuläret för en mässa, gränssnittet mot affärssystemet. Det som är beroende av en gammal version där märks annars först när det saknas.
Fas 2: Spärra och observera
Mellansteget förhindrar att en version tilldelas på nytt, utan att den raderas direkt. I Plesk finns möjligheten att inaktivera enskilda handlers. Enligt Plesk-dokumentationen går en inaktiverad handler inte längre att välja i en webbplats PHP-inställningar; versionen förblir installerad. På kommandoraden sker det med plesk bin php_handler --disable -id <handler-id>.
Domäner som fortfarande använder den gamla versionen ställer ni i förväg om, i samråd med de ansvariga, till en version som stöds. Hur det ser ut ur webbplatsägarens perspektiv beskrivs i inlägget Ändra PHP-version i hostingens kundområde. Valet av lämplig handler förklaras i inlägget Plesk: förstå PHP-handlers.
Under observationstiden bevakar ni felmeddelanden i loggarna, uteblivna cronjobb-resultat och återkoppling från användarna. I andra paneler heter funktionerna annorlunda; kontrollera där tillverkarens dokumentation.
Sätt slutet på observationstiden som ett datum och utse vem som därefter godkänner avinstallationen. Annars blir mellansteget ett permanent tillstånd, och den gamla versionen blir ändå kvar på servern.
Fas 3: Avinstallera
Först när observationstiden har gått utan anmärkningar tar ni bort versionen helt. I Plesk sker det enligt dokumentationen under Tools & Settings, Updates, Add/Remove Components, i området Web hosting vid PHP-tolkversionerna. Installerade versioner är markerade där och kan väljas för borttagning.
På servrar utan panel sköter pakethanteringen den uppgiften. Säkra i förväg versionens konfiguration, till exempel /etc/php/7.4/ under Debian och Ubuntu, så att ni i nödfall kan spåra vilka inställningar som gällde.
# Säkerhetskopiera konfigurationen och ta sedan bort paketen i en gren (exempel Debian/Ubuntu, PHP 7.4)
tar czf /root/php74-konfiguration.tar.gz /etc/php/7.4/
apt remove 'php7.4*'
Efter borttagningen lönar sig en kontroll. I Plesk rekommenderar dokumentationen plesk bin php_handler --reread för att läsa in handler-information på nytt efter ändringar av PHP-binärer. Kontrollera dessutom om tjänsteplaner fortfarande pekar på den borttagna versionen.
Typiska fallgropar
| Fallgrop | Så känner ni igen den | Vad som hjälper |
|---|---|---|
| Panelkomponent är beroende av versionen | Panelen meddelar ett beroende vid borttagning | Ställ först om komponenten eller behåll versionen |
| Tjänsteplan pekar på gammal version | Nya webbplatser får den gamla versionen eller ett felmeddelande | Justera planen, ta sedan bort versionen |
| Cronjobb anropar fast sökväg | Skriptet misslyckas efter borttagningen | Ändra sökvägen till en version som stöds |
| Applikation går inte på ny version | Fel efter omställningen i felloggen | Uppdatera eller migrera applikationen |
Går en applikation inte att lyfta till en version som stöds är avstängningen av den gamla versionen inte längre en konfigurationsfråga, utan ett migreringsprojekt. Riskerna med föråldrade grenar beskrivs i guiden PHP End of Life: risker med föråldrade versioner.
Nästa kandidat är redan känd
Städning är ingen engångsåtgärd. Redan den 31 december 2026 faller PHP 8.2 ur PHP-projektets support. Den som nu tar bort versioner upp till 8.1 bör i samma veva bestämma hur det går för 8.2. Annars börjar samma spel om på några veckor.
En enkel regel för servern har visat sig fungera: det erbjuds bara grenar som PHP-projektet stöder. Varje gren får vid uppsättningen ett datum då den granskas på nytt, med utgångspunkt i supportslutet på php.net. Bakgrunden till den cykeln förklaras på sidan PHP-versioner och releasecykel.
Den som är hoster eller byrå och har kunder på servern bör informera dem tidigt. Ett meddelande med datum, en uppmaning att ställa om och ett erbjudande om hjälp förhindrar att webbplatser faller bort på stoppdagen. Kunder vars applikation inte hänger med inser på så vis i tid att en uppdatering eller migrering väntar, och kan planera för det.
Hur hjälper PHP SOS konkret?
- Vi tar reda på vilka webbplatser, cronjobb och panelkomponenter som använder vilken PHP-version.
- Vi ställer om domäner i samråd till versioner som stöds och spärrar gamla handlers.
- Efter observationstiden tar vi bort gamla versioner kontrollerat och granskar resultatet.
- Där applikationer inte hänger med planerar vi migreringen från PHP 8.1 och äldre.
Vanliga frågor
Varför bör jag ta bort oanvända PHP-versioner?
Varje installerad version måste kontrolleras, uppdateras och startas om vid varje sårbarhet. Gamla grenar som PHP 8.1 och äldre får inga uppdateringar längre från PHP-projektet. Oanvända versioner ger bara risk och merarbete.
Vad är skillnaden mellan att inaktivera och att avinstallera?
Vid inaktivering finns versionen kvar installerad men går inte längre att välja på nytt. Vid avinstallation tas den bort från servern. Inaktivering är det säkra mellansteget för att se om något saknas.
Kan borttagningen av en PHP-version störa panelens funktioner?
Ja. Vissa komponenter i en panel, till exempel webbmail eller administrationsverktyg, är beroende av en viss PHP-version. Klargör sådana beroenden före borttagningen; panelen brukar uppmärksamma på dem.
Hur lång bör observationstiden vara?
Tillräckligt lång för att alla regelbundna förlopp har körts minst en gång, alltså även månatliga cronjobb och exporter. Fastställ längden tillsammans med fackavdelningarna.