Una actualización de PHP puede descubrir funciones eliminadas, tipos más estrictos, plugins codificados incompatibles o extensiones ausentes. Volver atrás puede recuperar el servicio temporalmente, pero mantener PHP sin soporte también crea riesgos de seguridad y compatibilidad.
Anota el entorno anterior y el nuevo antes de volver a cambiar. cPanel y Plesk pueden asignar versiones distintas a peticiones web, CLI y dominios individuales.
Confirma el entorno activo
Utiliza el panel o un diagnóstico temporal protegido para identificar versión, controlador y configuración cargada en el dominio que falla.
error_log( 'Diagnostic PHP: ' . PHP_VERSION . ' / ' . php_sapi_name() );Retira el diagnóstico después. No publiques phpinfo(): muestra rutas, módulos y datos del entorno.
Comprueba WP-CLI aparte; puede invocar otro binario.
Conserva el primer error de compatibilidad
Relaciona la petición fallida con el registro PHP. Son habituales funciones inexistentes, declaraciones incompatibles, errores de tipo y fallos al cargar ionCube u otra extensión.
Anota componente, línea y pila. No te centres en avisos de funciones obsoletas si un error fatal posterior es quien detiene la petición.
Conserva el registro antes de cambiar de entorno, porque la versión anterior puede producir otras pruebas.
Comprueba requisitos de WordPress y extensiones
Compara núcleo, tema, plugins y código propio con la versión PHP objetivo. Consulta declaraciones actuales y changelogs de cada fabricante.
Un plugin abandonado puede declarar compatibilidad amplia, pero contener rutas que ningún escáner ha ejecutado. Reproduce en staging las funciones reales de la web.
No confíes únicamente en una insignia de compatibilidad.
Construye una matriz de compatibilidad
Enumera PHP actual y objetivo junto al núcleo, tema activo, plugins esenciales y código propio. Marca soporte del fabricante, última versión probada y recorrido funcional verificado.
Prioriza autenticación, editor, tareas programadas, correo e integraciones, no solo el renderizado. En plugins cerrados, confirma que el cargador necesario tenga una compilación para la versión objetivo antes de producción.
Verifica las extensiones PHP necesarias
Las versiones pueden tener conjuntos de módulos distintos. Comprueba cURL, mbstring, XML, ZIP, GD o Imagick, intl y controladores de base de datos requeridos.
Una extensión puede estar instalada para PHP 8.1 y faltar en 8.3. Utiliza cPanel, Plesk o el gestor de paquetes compatible con el servidor.
No instales binarios arbitrarios ni desactives TLS para sortear la ausencia de un módulo de red.
Revisa controlador y configuración
La nueva versión puede utilizar otro pool FPM, límite de memoria, tamaño de subida, disable_functions, zona horaria o usuario de archivos.
Compara la configuración efectiva en vez de copiar todo el php.ini anterior. Una directiva retirada puede impedir que arranque el nuevo servicio.
Revisa OPcache y las rutas de sockets; quizá el servidor web siga apuntando al pool anterior.
Recupera el servicio con seguridad
Si producción está caída, selecciona temporalmente la última versión compatible y soportada mientras preparas la solución definitiva. Documenta la reversión y su fecha límite.
No restaures la base de datos para revertir PHP: el contenido no está relacionado y podrías perderlo.
Si el entorno anterior está fuera de soporte, limita la exposición y prioriza la compatibilidad.
Repara el componente incompatible
Actualiza o sustituye el plugin o tema señalado, corrige el PHP propio e instala las extensiones necesarias. Utiliza un tema hijo o plugin mantenido en vez de editar archivos del proveedor.
Prueba sintaxis y comportamiento en staging con el PHP objetivo. Retira supresiones de errores que oculten lógica inválida.
Limpia OPcache tras desplegar el código corregido.
Ejecuta una aceptación completa
Prueba plantillas públicas, acceso, editor, medios, correo, cron, REST API y cada integración importante. Revisa nuevos avisos que puedan anticipar futuras roturas.
El mantenimiento recurrente debería inventariar requisitos y probar versiones de PHP antes de que el hosting las imponga. Una actualización correcta significa que todo el recorrido funciona en una versión soportada, no simplemente que carga la portada.