Versiones de PHP: soporte y actualización segura

Actualizar el entorno de producción forma parte del mantenimiento del proyecto. Permite recibir correcciones, conservar la compatibilidad con las bibliotecas y preparar los siguientes cambios sin prisas. El equipo necesita conocer un plazo: cuánto tiempo seguirá recibiendo soporte la versión elegida y cuándo hará falta otra migración.

Conviene empezar por la tabla oficial de soporte de PHP. Ayuda a elegir una rama y planificar las actualizaciones. Migrar a PHP 8.5 tiene sentido si la aplicación, las dependencias y el alojamiento admiten esa rama. PHP 8.4 también puede ser una base adecuada si sigue recibiendo soporte y se ha comprobado con el proyecto.

Qué significa el soporte de una versión

PHP mantiene varias ramas. Cada una tiene su propio plazo de soporte.

• Soporte activo: el proyecto PHP corrige errores y vulnerabilidades y publica actualizaciones.
• Correcciones de seguridad: el soporte activo ha terminado; la rama recibe correcciones de problemas críticos de seguridad cuando hace falta.
• Fin del soporte, EOL: el proyecto PHP ya no mantiene la rama. Si sigue utilizándola, debe planificar una migración.

La política general de PHP ofrece unos dos años de soporte activo y otros dos de correcciones de seguridad. Consulte la fecha concreta de la rama en la tabla. Esa fecha importa más que un cálculo basado en la antigüedad de la versión.

Fechas contrastadas con PHP.net el 14 de octubre de 2026. Antes de elegir una versión, vuelva a consultar la fuente: también hay que mantener actualizada esta tabla del artículo.

La rama 8.4 y un lanzamiento concreto 8.4.x son decisiones distintas. El plazo hasta finales de 2028 corresponde a la rama. Para recibir las correcciones disponibles, debe instalar sus lanzamientos actualizados. Un antiguo PHP 8.4.0 no queda protegido solo porque la rama 8.4 siga recibiendo soporte.

El soporte de PHP 7.4, la última rama de la familia PHP 7, terminó el 28 de noviembre de 2022. El proyecto PHP tampoco mantiene las ramas anteriores de 7.x. El proveedor del sistema operativo o del alojamiento puede ofrecer un soporte separado con sus propias condiciones. No lo considere una continuación del soporte de PHP sin confirmación del proveedor.

Cómo elegimos PHP 8.4

En 2025 migramos los proyectos principales desde PHP 7.x, versiones antiguas de CentOS y BitrixEnv 7.x a Rocky Linux 9, BitrixEnv 9.x y PHP 8.4. Para elegir la rama, consultamos la misma tabla de PHP.net.

La tabla ofrecía una referencia clara: PHP 8.4 tiene previstas correcciones de seguridad hasta el 31 de diciembre de 2028. Ese plazo ayuda a distribuir el trabajo con antelación y preparar la siguiente migración. Dentro de la rama elegida siguen siendo necesarias las actualizaciones.

En octubre de 2026, tras las noticias sobre vulnerabilidades críticas en PHP, migramos rápidamente a PHP 8.5. Esta rama tiene previstas correcciones de seguridad hasta el 31 de diciembre de 2029.

Consideraremos la siguiente rama estable, PHP 8.6 o posterior, cuando se publique, si resulta adecuada para los proyectos. Es un plan provisional. La elección final dependerá de la compatibilidad de las aplicaciones, del soporte de la infraestructura y de las comprobaciones. Lo evaluaremos llegado el momento.

La tabla de PHP establece los plazos de PHP. No promete que toda la combinación reciba soporte hasta la misma fecha. Rocky Linux, BitrixEnv, Bitrix, el servidor web y las bibliotecas tienen sus propias condiciones y plazos; los comprobamos por separado.

Por qué mantener el software actualizado

Un entorno con soporte permite recibir correcciones y consultar documentación vigente. Reduce la dependencia de bibliotecas antiguas para las que ya no hay nuevos lanzamientos. Posponer las actualizaciones aumenta poco a poco el trabajo de la siguiente migración: hay que cambiar varias capas a la vez y resolver las incompatibilidades acumuladas.

Una versión nueva no garantiza por sí sola la seguridad ni la fiabilidad. También hacen falta ajustes correctos, permisos limitados, copias de seguridad y comprobaciones de la aplicación. El calendario de actualizaciones debe tener en cuenta el riesgo del cambio y la importancia del proyecto.

La actualización está lista cuando los procesos necesarios funcionan después de migrar. Si el sitio abre pero se ha detenido el intercambio de datos, todavía no podemos considerar que la actualización haya tenido éxito.

Dónde ayudan SRE y DevOps

SRE es el trabajo de ingeniería dedicado a la fiabilidad de un servicio. En una actualización, esto exige criterios claros: qué debe seguir funcionando, qué errores son inaceptables y qué señales nos harán volver a la versión anterior.

Las prácticas de DevOps ayudan a conectar el código con el entorno: gestionar los ajustes, repetir la compilación, comprobar las dependencias y publicar los cambios en un orden acordado. El desarrollador necesita saber qué PHP sirve el sitio, qué extensiones requiere la aplicación y dónde consultar los errores. El especialista en infraestructura necesita la lista de procesos importantes de los usuarios y de dependencias del proyecto.

Antes de actualizar, conviene acordar cuatro cosas:

1. Composición del entorno: versiones de PHP, sistema operativo, aplicación, extensiones y bibliotecas.
2. Criterios de comprobación: qué acciones del usuario e integraciones deben funcionar.
3. Recuperación: quién restaura el entorno anterior, dónde está la copia y cómo se recuperan los datos.
4. Supervisión después de publicar: errores, disponibilidad, tiempo de respuesta y ejecución de operaciones importantes.

Un proceso de publicación que se puede repetir y un método de recuperación comprobado ayudan al equipo a controlar el cambio. Estas prácticas también sirven sin un puesto específico de SRE o DevOps. En un alojamiento compartido, el proveedor realiza parte del trabajo; por eso conviene aclarar las responsabilidades de antemano.

Averigüe qué PHP se está ejecutando

En un alojamiento compartido, empiece por el panel: consulte la versión de PHP del dominio y las extensiones activadas. Pregunte al proveedor qué ajustes y registros están disponibles. Para ello no necesita acceso a bash.

Si el equipo dispone de un terminal en el servidor de pruebas o en un ordenador, ejecute:

php -v
php -m

El primer comando muestra la versión. El segundo muestra las extensiones. Si hay varias versiones instaladas, indique la ruta del ejecutable PHP que necesita. La versión del terminal y la que sirve el sitio pueden ser distintas y leer ajustes diferentes. No deje un phpinfo() público: revela información del entorno.

En un sitio multilingüe, compruebe UTF-8 y las extensiones necesarias. Por ejemplo, el procesador de Markdown puede utilizar mbstring para calcular sangrías con tabulaciones. Su ausencia puede manifestarse solo en un artículo.

Compruebe el código y los procesos reales

Para migrar de PHP 8.3 a 8.5, revise los cambios de ambas ramas intermedias: 8.4 y 8.5. PHP advierte que hay que comprobar las incompatibilidades antes de cambiar la versión en producción.

Si dispone de un terminal, puede comprobar la sintaxis desde la raíz del proyecto:

rg --files -g '*.php' -0 | xargs -0 -n 1 php -l

El comando requiere rg y xargs. Enumera los archivos PHP y comprueba la sintaxis con la versión elegida de PHP. No ejecuta los procesos del usuario. Si no dispone de una consola, utilice una copia de pruebas y las comprobaciones que pueda realizar el proveedor.

En el entorno de pruebas, active E_ALL y el registro de errores. Permita la visualización de errores solo en un entorno cerrado a los visitantes. Compruebe las páginas, los procesos en segundo plano y las integraciones del proyecto. Abra también RSS y sitemap: una advertencia PHP dentro del XML puede estropear el documento.

Corrija las construcciones obsoletas según los resultados de las comprobaciones. Por ejemplo, declare explícitamente que un parámetro admite null:

function loadTitle(?string $title = null): string
{
    return $title ?? 'Sin título';
}

En PHP 8.5, prefiera las conversiones habituales (int), (bool), (float) y (string). En código nuevo, no utilice los nombres obsoletos (integer), (boolean), (double) y (binary). No oculte las advertencias con el operador @; averigüe la causa y compruebe el cambio con datos de entrada reales.

Conserve la protección y prepare la vuelta a la versión anterior

Los tipos estrictos no sustituyen la validación de entradas ni el escape de la salida. Un parámetro de la URL puede ser un array en lugar de una cadena. Compruebe el tipo y después busque el registro en el catálogo conocido. No pase a include una ruta proporcionada por el usuario.

Para texto dentro de HTML, indique la codificación:

function escapeHtml(string $text): string
{
    return htmlspecialchars($text, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');
}

JSON, las URL y otros contextos necesitan sus propios métodos de codificación. Procese en modo seguro el Markdown que contenga HTML de terceros.

Guarde los archivos, los ajustes y los datos si el proyecto utiliza una base de datos. Compruebe la recuperación en una copia de pruebas. Si actualiza el sistema operativo o la estructura de datos, restaurar los archivos puede no bastar. Acuerde el método de recuperación de antemano.

Después de publicar, repita los procesos principales y consulte el registro de errores. Desactive la visualización de errores para los visitantes. La compatibilidad se confirma ejecutando las comprobaciones con la versión elegida de PHP. La fiabilidad depende de que el servicio funcione y de poder recuperarlo si falla.

Fuentes

• PHP: plazos de soporte de las ramas.
• PHP: ramas cuyo soporte ha terminado.
• Migración a PHP 8.4.
• Migración a PHP 8.5.
• Opciones de la línea de comandos de PHP.
• Errores y seguridad.
• Escape de HTML.
• Google SRE: publicación reproducible de software.
• Formato del código PSR-12.

Las migraciones a PHP 8.4 en 2025 y a PHP 8.5 en 2026, así como el plan para la siguiente rama, se describen a partir de la experiencia de nuestro equipo. Las comprobaciones y recomendaciones de los apartados posteriores no son un informe de los pasos realizados en aquellas migraciones.