Si su proveedor de alojamiento le anuncia el fin de PHP 7.4, 8.0 o 8.1, este es el orden a seguir: hacer una copia de seguridad del sitio, actualizar WordPress o Joomla, el tema y los plugins, probar el sitio en una copia con PHP 8.3, y solo entonces cambiar la versión en el proveedor y verificar los formularios. Cuente una a dos horas para un sitio vitrina, medio día para una tienda. Estas tres versiones de PHP ya no reciben parches de seguridad: PHP 7.4 desde el 28 de noviembre de 2022, PHP 8.0 desde el 26 de noviembre de 2023, PHP 8.1 hasta el 31 de diciembre de 2025. PHP 8.2 finalizará el 31 de diciembre de 2026. Fechas verificadas el 9 de noviembre de 2026 en php.net y las páginas de ayuda de los proveedores.
Realizo estas actualizaciones a distancia desde octubre de 2026, para artesanos, despachos, asociaciones y PYMES. El caso típico: un sitio construido entre 2015 y 2019, nunca actualizado, y un proveedor que ya no responde.
¿Por qué su proveedor de alojamiento le escribe ahora?
PHP es el lenguaje que ejecuta WordPress y Joomla. Cada versión tiene una vida útil de cuatro años, de los cuales solo dos son para correcciones de seguridad. Después, nada más. Al 9 de noviembre de 2026, el proyecto PHP solo sigue 8.2 y 8.3, en modo seguro, y 8.4 y 8.5. PHP 8.2 finalizará el 31 de diciembre de 2026; le dediqué un artículo aparte.
Dos cosas aceleraron los correos este otoño: el fin de PHP 8.1 el 31 de diciembre de 2025, y luego las dos vulnerabilidades críticas del 21 de octubre de 2026, que permiten ejecutar código a distancia. El proyecto PHP publicó parches ese día para 8.2.35, 8.3.36, 8.4.27 y 8.5.12, y para nada más; un sitio en 7.4, 8.0 o 8.1 no recibió nada. Detallé este episodio en mi artículo sobre la falla PHP de octubre de 2026. Los proveedores que no quieren asumir este riesgo cierran las ramas antiguas o las hacen pagar.
Cómo leer el correo de su proveedor de alojamiento
Busque tres informaciones: la versión afectada, la fecha en que será retirada o cobrada, y qué hará el proveedor por su cuenta. Este último punto lo cambia todo. Páginas de ayuda releídas el 9 de noviembre de 2026.
En OVHcloud, la página «Versiones disponibles de los lenguajes», actualizada el 27 de octubre de 2026, clasifica PHP 8.1 como finalizada desde el 31 de diciembre de 2025 y marca las versiones 8.0 a 5.3 como «Migración recomendada». Siguen listadas, sin cambio automático ni fecha de retiro anunciada, y la compatibilidad del sitio sigue siendo su responsabilidad. Mi guía OVHcloud muestra dónde cambiar la versión.
En IONOS, la página de ayuda «PHP Extended Support» describe un servicio pagado que comienza al finalizar el soporte comunitario: IONOS corrige por sí mismo las versiones antiguas, desde PHP 5.6 hasta 8.2, y cobra una tarifa mensual, no especificada en la página, después de un período de transición gratuita anunciado por correo. Se detiene al pasar a una versión soportada y luego cancelando la opción. Ver mi guía IONOS.
En Hostinger, el artículo de ayuda indica que las versiones 8.1 y anteriores ya no están disponibles en el panel, que los nuevos sitios comienzan con PHP 8.3, y que un sitio existente mantiene su versión hasta que usted la actualice. No es posible retroceder, excepto dentro de la misma sesión. Ver mi guía Hostinger.
En Infomaniak, la FAQ « Modificar la versión de PHP de un sitio », actualizada el 2 de noviembre de 2026, indica que los parches del 21 de octubre se desplegaron desde PHP 7.4 hasta 8.5, con números de versión sin cambios. Es, junto con la opción de pago de IONOS, el único caso de esta lista donde una rama antigua aún recibe parches. Infomaniak recomienda, sin embargo, una versión reciente, y advierte que no hay vuelta atrás hacia una versión vulnerable. Ver mi guía de Infomaniak.
En o2switch, la página « Seleccionar una versión de PHP », actualizada el 23 de junio de 2026, sigue listando PHP 4.4 a 8.5 en el selector de cPanel, sin mencionar la retirada de versiones antiguas ni los parches. Ver mi guía de o2switch y aquella para PlanetHoster.
Verifica la versión realmente servida por tu sitio
El correo habla de la oferta, no necesariamente de tu sitio. En WordPress, ve a Herramientas, Salud del sitio, pestaña Información, sección Servidor. En Joomla, ve a Sistema, luego Información del sistema. Sin acceso, mi herramienta Falla PHP, verificar mi sitio lee la versión que tu sitio anuncia y reconoce el alojamiento, sin necesidad de instalar nada.
Una trampa: un archivo .htaccess o .ovhconfig olvidado en una carpeta puede servir una versión distinta a la del panel. La versión servida es la que cuenta, y la verifico antes de cifrar.
Lo que WordPress y Joomla esperan para el 9 de noviembre de 2026
WordPress.org recomienda PHP 8.3 o superior, y aclara que WordPress sigue funcionando con PHP 7.4, versión en fin de vida que puede exponer el sitio. « Funciona aún » no es lo mismo que « está protegido ».
Joomla es más estricto. Joomla 5.4 exige PHP 8.1.0 y recomienda 8.3; la rama 5 solo recibe parches de seguridad hasta el 12 de octubre de 2027. Joomla 6, lanzado el 14 de octubre de 2025, exige PHP 8.3.0 y recomienda 8.4. Un Joomla 3 o 4 dejó de tener soporte desde el 14 de octubre de 2025 como muy tarde: hay que migrarlo antes de hablar de PHP.
Lo que más suele fallar al pasar de PHP 7 a PHP 8
Cambiar de versión no afecta tus textos ni imágenes: lo que cambia son las reglas que el código del tema y las extensiones debe cumplir. Tres familias de problemas aparecen una y otra vez, todas documentadas en las guías de migración de php.net.
Las funciones eliminadas. PHP 8.0 eliminó create_function(), each() y money_format(), aún presentes en temas y extensiones antiguos. Llamar a una función que ya no existe provoca un error fatal: la página en blanco. Más antiguo, PHP 7.0 eliminó la extensión mysql, y un sitio de 2015 con código propio choca con eso primero.
Las comparaciones. En PHP 8, « 0 == 'texto' » es falso cuando en PHP 7 era verdadero, y una operación sobre una cadena no numérica lanza un error en lugar de una advertencia.
Las advertencias de depreciación. PHP 8.1 advierte sobre el paso de null a una función interna; PHP 8.2 advierte sobre propiedades dinámicas, la escritura « ${variable} » en una cadena y utf8_encode(). Nada fatal, pero si el mostrado de errores está activo, los mensajes se imprimen al inicio de las páginas y pueden romper las redirecciones. Detrás de todo esto, casi siempre hay una extensión abandonada desde hace años, que debe reemplazarse.
¿En qué orden actuar para no terminar con una página en blanco?
La página en blanco después de un cambio hecho « por si acaso », sin copia de seguridad ni prueba, es la solución de emergencia que veo con más frecuencia. El orden es más importante que la técnica.
Primero, una copia de seguridad completa, archivos y base de datos, almacenada en otro lugar que en el alojamiento. Luego, las actualizaciones de WordPress o Joomla, del tema y de las extensiones, en la versión actual de PHP. Después, la selección: una extensión desactivada desde hace dos años se elimina. Luego, la prueba en una copia del sitio con la versión objetivo, subdominio o servidor de prueba: ahí es donde aparecen las funciones eliminadas, no en producción. Solo después, el cambio de versión en el sitio real, seguido de la verificación de las páginas clave: inicio, formularios, pago, administración. Mi herramienta Probar mi sitio realiza ocho controles rápidos de la página de inicio, incluyendo la versión de PHP; no reemplaza la prueba manual de los formularios.
La prueba en copia no es un lujo: en Infomaniak, no hay retorno a una versión vulnerable; en Hostinger, solo dentro de la misma sesión.
¿Hacerlo uno mismo, pedirle al alojador o recurrir a un desarrollador?
Hágalo usted mismo si el sitio es un WordPress reciente, actualizado, con menos de una decena de extensiones, y si sabe restaurar su copia de seguridad. El cambio toma unos minutos en el panel del alojador, y WordPress.org ofrece una guía « Actualizar PHP » con un módulo de verificación de compatibilidad, imperfecto según su propio reconocimiento.
Pida al alojador cuando el bloqueo es de su parte: versión ausente del panel, opción pagada que debe cancelarse. El alojador cambia la versión. No actualiza su tema, no reemplaza una extensión abandonada y no corrige su código.
Recurra a un desarrollador si el sitio data de 2015-2019 y no ha cambiado desde entonces, si su proveedor ha desaparecido, si el tema es personalizado, si es una tienda, o si no tiene una copia de seguridad de la que esté seguro.
Cómo procedo, a distancia, desde octubre de 2026
Me envía la dirección del sitio. En menos de 24 horas, recibe un diagnóstico escrito y gratuito: versión de PHP realmente servida, plataforma, alojador. Luego, recupero los accesos, hago una copia de seguridad completa fuera del servidor y trabajo en una copia. Actualizo WordPress o Joomla, el tema y las extensiones, paso la copia a PHP 8.3 o 8.4 y corrijo lo que aparece. Cuando la copia está lista, cambio la versión en el sitio real, pruebo los formularios, el pago y las páginas principales, y le envío un informe escrito: lo que se hizo, lo que queda por vigilar. Nada se modifica sin su acuerdo escrito sobre el precio, y el sitio nunca se corta sin avisarle.
Preguntas frecuentes
¿Quién puede actualizar la versión de PHP de mi sitio? Usted, desde el panel de su alojador, si tiene los accesos y una copia de seguridad. El soporte del alojador, solo para el cambio de versión. Un desarrollador web, para el conjunto: actualizaciones del sitio, pruebas, corrección de lo que falla. La agencia o freelance que creó el sitio es el primero a contactar; si no responde, cualquier desarrollador PHP puede retomar un WordPress o Joomla a distancia.
¿Mi alojador puede hacerlo por mí? Puede cambiar la versión de PHP si se lo pide, o retirar la antigua de su oferta. No actualiza su WordPress, su tema ni sus extensiones, y no repara lo que falla después. OVHcloud escribe que la compatibilidad sigue siendo su responsabilidad; IONOS mantiene la versión antigua bajo suscripción; Hostinger ha retirado PHP 8.1 y versiones anteriores de su panel.
Mi sitio sigue funcionando en PHP 7.4, ¿por qué cambiar? Porque « funciona » y « protegido » son dos cosas distintas. PHP 7.4 no ha recibido ninguna corrección de php.net desde el 28 de noviembre de 2022, y nada para las vulnerabilidades del 21 de octubre de 2026. Un sitio que se muestra normalmente puede ya estar sirviendo para enviar spam o alojar páginas fraudulentas.
¿Qué versión de PHP elegir en noviembre de 2026? PHP 8.3 como mínimo, 8.4 si su tema y extensiones lo permiten. WordPress.org recomienda 8.3 o superior, Joomla 6 lo exige. PHP 8.2 sigue funcionando, pero ya no recibirá actualizaciones después del 31 de diciembre de 2026: mejor realice la operación en enero.
¿Qué hacer si mi sitio muestra una página en blanco después del cambio? Vuelva a la versión anterior desde el panel si aún es posible: el sitio volverá a funcionar. Luego revise el registro de errores del alojamiento: la primera línea indica el archivo culpable, casi siempre una extensión o el tema. Désactívelo por FTP renombrando su carpeta y vuelva a seguir el orden descrito anteriormente. Sin copia de seguridad, no toque nada más y pida ayuda.
¿Cuánto tiempo y cuánto cuesta? Una o dos horas para un sitio web básico, medio día para una tienda en línea, a distancia. Mis paquetes públicos son de 190 € para un sitio web básico y de 390 € para una tienda en línea, incluyendo diagnóstico gratuito. También existe un seguimiento de 100 € al mes para quienes no desean recibir este tipo de correos.
Si acaba de recibir este correo, envíeme la dirección de su sitio: el diagnóstico es gratuito y llegará por escrito en menos de 24 horas. Los detalles están en mi página actualizada a PHP.
