En resumen: La forma más segura de desactivar versiones antiguas de PHP es en tres fases: determinar el uso, bloquear la versión y observar, y solo entonces desinstalar. En Plesk, un handler puede desactivarse primero, de modo que ya no se pueda elegir, y eliminarse más tarde en Actualizaciones y componentes. Cada versión eliminada es una menos que tendrá que parchear y reiniciar ante la próxima vulnerabilidad como PHP2Shell.
¿Por qué limpiar precisamente ahora?
La semana posterior a PHP2Shell mostró a muchos administradores cuántas versiones de PHP hay instaladas en sus servidores. Cada una tuvo que revisarse, cada una necesitó una actualización o medidas provisionales y cada servicio un reinicio. Para PHP 8.1 y anteriores solo hay backports mínimos del código fuente, y para PHP 8.2 el soporte termina el 31 de diciembre de 2026.
Con esa experiencia aún fresca, es el momento adecuado para limpiar. Cómo localizar todas las instalaciones lo describe el artículo Varias versiones de PHP en un servidor. Aquí se trata del paso siguiente: la desactivación controlada.
Fase 1: determinar el uso
Antes de desactivar nada, debe saber quién utiliza una versión. Los sitios web son la parte evidente. Menos visibles son los subdominios, las instalaciones de prueba, las tareas cron, los scripts y los componentes del panel.
En Plesk, el comando plesk bin php_handler --list enumera todos los handlers registrados. Con --get-usage, según la documentación, Plesk muestra qué dominios usan un handler determinado. Ninguno de los dos comandos modifica nada.
# Plesk: todos los handlers y los dominios que usan un handler
plesk bin php_handler --list
plesk bin php_handler --get-usage -id <handler-id>
# En general: tareas cron que llaman a una versión de PHP determinada
grep -rE "php(7|8\.0|8\.1)" /etc/crontab /etc/cron.d /var/spool/cron 2>/dev/null
Revise además los registros de acceso de los sitios afectados: una instalación de prueba que no ha recibido ninguna petición en meses es candidata a eliminarse, no a migrarse. Anote para cada versión antigua quién la usa y por qué.
Pregunte también a las personas que trabajan con los sitios web. Las redacciones, agencias y departamentos suelen conocer procesos que no figuran en ninguna lista: la exportación anual para contabilidad, el formulario de una feria, la interfaz con el sistema de gestión de mercancías. Lo que dependa allí de una versión antigua, de lo contrario, solo se descubre cuando falla.
Fase 2: bloquear y observar
El paso intermedio impide que se asigne de nuevo una versión sin borrarla de inmediato. En Plesk existe para ello la posibilidad de desactivar handlers concretos. Según la documentación de Plesk, un handler desactivado ya no se puede seleccionar en los ajustes de PHP de un sitio web; la versión sigue instalada. En la línea de comandos se hace con plesk bin php_handler --disable -id <handler-id>.
Los dominios que aún usan la versión antigua, páselos antes a una versión compatible, de acuerdo con los responsables. Cómo lo ve el operador de un sitio web lo describe el artículo Cambiar la versión de PHP en el área de cliente del alojamiento. La elección del handler adecuado la explica el artículo Plesk: entender los handlers de PHP.
Durante el período de observación, preste atención a los mensajes de error en los registros, a los resultados ausentes de tareas cron y a los comentarios de los usuarios. En otros paneles las funciones tienen otros nombres; consulte allí la documentación del fabricante.
Fije como fecha el final del período de observación y nombre a quién autoriza la desinstalación después. De lo contrario, el paso intermedio se convierte en un estado permanente y la versión antigua acaba quedándose en el servidor.
Fase 3: desinstalar
Solo cuando el período de observación haya transcurrido sin incidencias, elimine la versión por completo. En Plesk, según la documentación, se hace en Tools & Settings, Updates, Add/Remove Components, en el área Web hosting, en las versiones del intérprete de PHP. Las versiones instaladas están marcadas allí y se pueden seleccionar para eliminarlas.
En servidores sin panel, de esta tarea se encarga la gestión de paquetes. Antes, haga una copia de la configuración de la versión, por ejemplo /etc/php/7.4/ en Debian y Ubuntu, para poder reconstruir en caso de emergencia qué ajustes estaban vigentes.
# Copia de la configuración y después eliminar los paquetes de una rama (ejemplo Debian/Ubuntu, PHP 7.4)
tar czf /root/php74-konfiguration.tar.gz /etc/php/7.4/
apt remove 'php7.4*'
Tras la eliminación merece la pena una comprobación. En Plesk, la documentación recomienda plesk bin php_handler --reread para volver a leer la información de los handlers después de cambios en los binarios de PHP. Compruebe además si los planes de servicio siguen apuntando a la versión eliminada.
Obstáculos típicos
| Obstáculo | Cómo se reconoce | Qué ayuda |
|---|---|---|
| Un componente del panel depende de la versión | El panel avisa de una dependencia al eliminar | Cambiar primero el componente o conservar la versión |
| Un plan de servicio apunta a la versión antigua | Los sitios nuevos reciben la versión antigua o un mensaje de error | Ajustar el plan y después eliminar la versión |
| Una tarea cron llama a una ruta fija | El script falla tras la eliminación | Cambiar la ruta a una versión compatible |
| La aplicación no funciona en la versión nueva | Error en el registro de errores tras el cambio | Actualizar o migrar la aplicación |
Si una aplicación no se puede llevar a una versión compatible, desactivar la versión antigua deja de ser una cuestión de configuración y pasa a ser un proyecto de migración. Los riesgos de las ramas obsoletas los describe la guía PHP end of life: riesgos de las versiones obsoletas.
El próximo candidato ya está decidido
Limpiar no es una acción única. Ya el 31 de diciembre de 2026, PHP 8.2 deja de recibir soporte del proyecto PHP. Quien elimina ahora versiones hasta la 8.1 debería fijar a la vez qué pasa con la 8.2. De lo contrario, el mismo juego empieza de nuevo en pocas semanas.
Ha dado buen resultado una regla sencilla para el servidor: se ofrecen solo las ramas que el proyecto PHP admite. Al configurar cada rama se le asigna una fecha en la que se vuelve a revisar, orientada al fin del soporte en php.net. Los antecedentes de este ciclo los explica la página Versiones de PHP y ciclo de lanzamiento.
Quien como hoster o agencia tenga clientes en el servidor debería informarles pronto. Un aviso con fecha, la petición de cambio y una oferta de apoyo evitan que los sitios web dejen de funcionar el día señalado. Los clientes cuya aplicación no se adapte reconocen así a tiempo que se avecina una actualización o una migración y pueden planificarla.
¿Cómo ayuda PHP SOS en concreto?
- Determinamos qué sitios web, tareas cron y componentes del panel usan qué versión de PHP.
- Pasamos los dominios a versiones compatibles, de acuerdo con usted, y bloqueamos los handlers antiguos.
- Tras el período de observación eliminamos las versiones antiguas de forma controlada y comprobamos el resultado.
- Donde las aplicaciones no se adaptan, planificamos la migración de PHP 8.1 y anteriores.
Preguntas frecuentes
¿Por qué debería eliminar versiones de PHP sin uso?
Cada versión instalada debe revisarse, actualizarse y reiniciarse ante cada vulnerabilidad. Las ramas antiguas como PHP 8.1 y anteriores ya no reciben actualizaciones del proyecto PHP. Las versiones sin uso solo aportan riesgo y trabajo.
¿Cuál es la diferencia entre desactivar y desinstalar?
Al desactivar, la versión sigue instalada, pero ya no se puede volver a seleccionar. Al desinstalar, se elimina del servidor. Desactivar es el paso intermedio seguro para ver si algo falla.
¿Puede la eliminación de una versión de PHP afectar a funciones del panel?
Sí. Algunos componentes de un panel, como el webmail o las herramientas de administración, dependen de una versión concreta de PHP. Aclare esas dependencias antes de eliminar; por lo general, el panel lo advierte.
¿Cuánto debe durar el período de observación?
El suficiente para que todos los procesos periódicos se hayan ejecutado al menos una vez, incluidas las tareas cron y exportaciones mensuales. Fije la duración con los departamentos.