WordPress falla tras actualizar PHP: causas y soluciones

Una web puede funcionar durante años sobre una versión antigua de PHP y mostrar un error crítico, una pantalla en blanco o respuestas HTTP 500 justo después de actualizar el servidor. Esto no significa que la actualización sea incorrecta. Normalmente revela código antiguo que dependía de comportamientos que PHP ya no permite.

Volver temporalmente a la versión anterior puede recuperar el servicio, pero no resuelve el problema. Si esa rama de PHP ha terminado su ciclo de soporte, dejarla activa aumenta la exposición a vulnerabilidades que ya no recibirán correcciones oficiales. La solución responsable consiste en localizar la incompatibilidad, actualizar o sustituir el componente afectado y completar la migración con un procedimiento controlado.

Por qué WordPress funciona antes de actualizar PHP

WordPress no se ejecuta solo. Cada petición pasa por varias capas: servidor web, PHP, núcleo de WordPress, plugins, tema, código personalizado, base de datos, caché y servicios externos. El sitio puede ser compatible con una versión antigua de PHP porque todos esos componentes fueron desarrollados o configurados alrededor de ella.

Al actualizar PHP, cambia el intérprete que ejecuta el núcleo, los plugins y el tema. Las versiones modernas eliminan funciones obsoletas, aplican validaciones de tipos más estrictas, modifican algunas respuestas internas y generan errores donde antes únicamente aparecía una advertencia.

Por eso, el hecho de que una web funcionara antes de la actualización no demuestra que su código estuviera en buen estado. Puede haber acumulado deuda técnica silenciosa durante años. La actualización simplemente hace visible esa deuda.

Causas habituales del fallo después del cambio

Plugins antiguos o abandonados

Los plugins son una de las causas más frecuentes. Un complemento sin mantenimiento puede utilizar funciones eliminadas, acceder a variables que no existen, pasar valores nulos a funciones que esperan otro tipo de dato o declarar métodos con firmas incompatibles.

El registro de errores suele mostrar rutas como esta:

/wp-content/plugins/nombre-del-plugin/archivo.php

Si el fallo desaparece al desactivar ese plugin, no conviene limitarse a ocultar el error. Primero debe buscarse una actualización compatible. Si el desarrollador ha abandonado el proyecto, la opción más segura es sustituirlo por una alternativa mantenida o reprogramar únicamente la funcionalidad necesaria.

Temas y constructores visuales desactualizados

Un tema también ejecuta PHP. El problema puede estar en el archivo functions.php, en una plantilla sobrescrita, en un constructor visual o en una función añadida directamente por un proveedor anterior.

Actualizar el tema principal sin revisar las personalizaciones puede sobrescribir cambios. Por eso las modificaciones deberían residir en un tema hijo o en un plugin específico del proyecto. Esta separación permite actualizar el producto original y corregir el código personalizado sin mezclar responsabilidades.

Código personalizado incompatible

Los saltos entre ramas importantes de PHP endurecen el comportamiento del lenguaje. Algunos patrones que requieren revisión son:

• Llamadas a funciones eliminadas o marcadas como obsoletas.
• Acceso a índices de arrays cuando la variable puede ser null o false.
• Parámetros con tipos incorrectos que antes se convertían automáticamente.
• Firmas incompatibles entre métodos de una clase padre y una clase hija.
• Propiedades creadas dinámicamente sin estar declaradas en la clase.
• Dependencias que esperan recursos internos donde PHP ahora utiliza objetos.
• Librerías incluidas manualmente y nunca actualizadas.

El mensaje de error es importante. Un TypeError, por ejemplo, exige revisar qué valor está llegando a la función. Añadir un operador para silenciar el mensaje puede ocultar el síntoma, pero no corrige la entrada defectuosa.

Dependencias gestionadas con Composer

Algunos plugins personalizados y proyectos WordPress utilizan Composer. Aunque el código propio sea compatible, una dependencia bloqueada en una versión antigua puede impedir la actualización.

Conviene revisar composer.json y composer.lock, comprobar las restricciones de plataforma y actualizar las dependencias en un entorno de desarrollo. El archivo de bloqueo no debe eliminarse sin entender el impacto, porque determina las versiones exactas utilizadas por el proyecto.

Extensiones y configuración del servidor

No todos los fallos proceden del código de WordPress. El nuevo entorno puede carecer de extensiones como curl, mbstring, intl, mysqli, zip o soporte de imágenes. También pueden cambiar límites de memoria, tiempo de ejecución, tamaño de subida, zona horaria u opciones de OPcache.

Es recomendable comparar la configuración anterior y la nueva mediante el panel del hosting, WP-CLI o una salida temporal de phpinfo(). Este último archivo debe eliminarse inmediatamente después de la revisión, ya que puede exponer datos sensibles del servidor.

Por qué mantener PHP obsoleto es un riesgo de seguridad

Las ramas de PHP tienen un ciclo de soporte. Durante un periodo reciben correcciones generales y, posteriormente, únicamente actualizaciones críticas de seguridad. Cuando finaliza ese ciclo, las vulnerabilidades descubiertas dejan de corregirse oficialmente.

Un servidor desactualizado no implica que la web ya haya sido comprometida, pero sí amplía la superficie de ataque. Los atacantes utilizan herramientas automatizadas para buscar instalaciones vulnerables, plugins conocidos, credenciales expuestas y configuraciones inseguras. No necesitan elegir manualmente cada empresa.

Un firewall de aplicaciones, un CDN o un plugin de seguridad pueden reducir determinados ataques, pero no sustituyen los parches del sistema. Mantener versiones antiguas para conservar un plugin abandonado equivale a trasladar un problema de compatibilidad al terreno de la ciberseguridad.

También es importante distinguir los síntomas. Un error inmediatamente posterior al cambio de PHP suele indicar incompatibilidad. Redirecciones extrañas, usuarios administradores desconocidos, archivos modificados, tareas programadas sospechosas o código ofuscado pueden señalar un compromiso y requieren una investigación adicional.

Cómo encontrar el componente que está rompiendo la web

Trabajar primero en staging

La investigación debe realizarse sobre una copia de pruebas que reproduzca la configuración de producción. Antes de empezar hay que disponer de una copia verificable de los archivos, la base de datos y la configuración del servidor.

Una copia de seguridad solo es útil si puede restaurarse. Conviene comprobar el procedimiento de recuperación y definir de antemano cómo volver al estado anterior si la intervención supera la ventana de mantenimiento.

Activar el registro de WordPress de forma segura

En staging pueden habilitarse temporalmente las herramientas de diagnóstico de WordPress:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

Esta configuración registra avisos y errores sin mostrarlos a los visitantes. El archivo wp-content/debug.log debe protegerse, revisarse y eliminarse al terminar. En producción no deberían quedar activos registros públicos ni mensajes técnicos visibles.

Localizar el primer error fatal

El primer error fatal suele ser más útil que las decenas de mensajes posteriores. Hay que registrar la hora, la ruta del archivo, la línea, el tipo de excepción y la traza. Después se compara esa información con los logs de PHP-FPM, Apache, Nginx o el panel del proveedor.

Si no es posible acceder al administrador, se pueden desactivar los plugins renombrando temporalmente su directorio o mediante WP-CLI. Después se reactivan uno a uno hasta reproducir el fallo. El mismo procedimiento puede aplicarse al tema, activando durante la prueba un tema estándar compatible.

Comprobar todas las rutas funcionales

Que la portada cargue no significa que la migración esté terminada. Deben probarse el acceso al administrador, formularios, buscador, envío de correos, tareas programadas, edición de contenidos, subida de archivos, integraciones externas, procesos de compra y operaciones ejecutadas por AJAX o la API REST.

Las advertencias de funciones obsoletas también merecen atención. Aunque hoy no detengan la aplicación, anticipan problemas en futuras actualizaciones.

Plan seguro para actualizar PHP sin romper WordPress

1. Inventariar el sistema: registrar núcleo, tema, plugins, código propio, integraciones, extensiones PHP y configuración del hosting.
2. Eliminar componentes innecesarios: borrar plugins y temas que no se usan reduce código ejecutable y superficie de ataque.
3. Actualizar WordPress y sus extensiones: aplicar primero las versiones compatibles disponibles, siempre con respaldo y pruebas.
4. Analizar el código personalizado: utilizar pruebas automatizadas, análisis estático y reglas de compatibilidad. Estas herramientas orientan, pero no sustituyen las pruebas funcionales.
5. Replicar el cambio en staging: utilizar la misma rama de PHP, extensiones y configuración previstas para producción.
6. Corregir por orden de impacto: empezar por los errores fatales, continuar con integraciones y finalizar con advertencias y código obsoleto.
7. Medir el comportamiento: comparar tiempos de respuesta, consumo de memoria, errores, tareas programadas y funcionamiento de la caché.
8. Desplegar con una ventana controlada: preparar modo de mantenimiento, monitorización y un rollback documentado.
9. Vigilar después del despliegue: revisar logs, disponibilidad, conversiones, correos y alertas durante las horas posteriores.

El rollback debe existir como medida de contingencia, pero no como estrategia permanente. Si es necesario volver temporalmente a la rama anterior, debe abrirse una tarea prioritaria con responsable, fecha y solución técnica definida.

Qué revisar si hay indicios de un ataque

En una web sospechosa no basta con actualizar PHP. Hay que comprobar la integridad de los archivos del núcleo, revisar plugins obligatorios, directorios de subidas, usuarios administradores, tareas de wp-cron, claves secretas, sesiones activas y modificaciones recientes.

También deben rotarse las credenciales del hosting, SFTP, base de datos y WordPress; renovar las claves de seguridad; eliminar cuentas desconocidas y actualizar todos los componentes. Restaurar una copia sin cerrar la vía de entrada puede provocar una nueva infección.

Después de estabilizar el sitio, conviene establecer una política continua: versiones soportadas, actualizaciones periódicas, copias externas, mínimo privilegio, autenticación multifactor, monitorización de cambios y un staging operativo. Así, la siguiente actualización de PHP será una tarea planificada y no una emergencia.

Si tu WordPress solo funciona sobre una versión obsoleta de PHP, K&J Open Solutions puede auditar plugins, temas, código personalizado y configuración del servidor para completar la actualización sin comprometer la continuidad del negocio.