WordPress con error de PHP 8 tras cambio de hosting
Error php 8 wordpress tras migrar hosting: diagnostica la causa, revisa logs y corrige incompatibilidades paso a paso con seguridad.
Cuando aparece un error php 8 wordpress justo después de una migración, lo más habitual es que el problema no sea la copia en sí, sino una diferencia entre entornos. El nuevo hosting puede estar usando otra versión de PHP, límites distintos de memoria o ejecución, extensiones no idénticas, otro modo de caché o una configuración diferente de Apache, Nginx o PHP-FPM. A eso se suma que algunos plugins, temas o constructores visuales pueden comportarse bien en un servidor y fallar en otro si la versión concreta no está preparada para PHP 8 o si depende de ajustes específicos.
En la práctica, este tipo de fallo puede mostrarse como pantalla en blanco, mensaje de error fatal, backend inaccesible, error HTTP 500 o advertencias más discretas, según la configuración del servidor y si la salida de errores está visible o no. Por eso conviene diagnosticar primero qué componente falla realmente antes de actualizar, desactivar o tocar archivos en producción.
La buena noticia es que, con un proceso ordenado, suele ser posible aislar la causa con bastante precisión: revisar versión de PHP, activar el registro de errores, comprobar compatibilidad del tema y plugins, y validar la configuración del nuevo hosting tras el cambio.
Qué suele provocar un error de PHP 8 en WordPress tras cambiar de hosting
Tras un cambio de hosting WordPress, un error relacionado con PHP 8 puede deberse a varias capas técnicas. No conviene asumir una causa única: WordPress puede cargar correctamente, pero un plugin antiguo, una librería del tema o una extensión del servidor puede dejar de responder como antes.
Respuesta breve: tras una migración, el fallo suele venir de una diferencia de versión o configuración entre el hosting anterior y el nuevo. Lo primero es comprobar la versión de PHP del servidor, revisar compatibilidades de plugins y tema, y consultar los logs antes de aplicar cambios.
- Versión de PHP distinta a la del servidor anterior. Un sitio que funcionaba con PHP 7.4 puede fallar al pasar a PHP 8.1 o 8.2 si algún componente no se ha actualizado.
- Plugins o tema con compatibilidad parcial. No todos los errores implican que el plugin sea “incompatible” en general; a veces afecta solo a una versión concreta o a una función usada en un entorno determinado.
- Extensiones PHP no activas en el nuevo hosting. Según la configuración del proveedor, pueden variar módulos como
mbstring,curl,intl,imagickozip, entre otras. - Límites distintos de memoria o ejecución. Un fatal error puede aparecer si el nuevo servidor asigna menos memoria o corta procesos más pronto.
- Caché del servidor o del plugin. Si el hosting usa caché a nivel de aplicación, proxy o PHP-FPM, puede mostrar un comportamiento confuso tras la migración.
- Cambios en rutas, permisos o propietario de archivos. No siempre es un problema de PHP puro, pero puede manifestarse como error fatal o backend caído.
En resumen, el error no suele estar en “WordPress” como bloque único, sino en la interacción entre WordPress, PHP 8, el código de terceros y la configuración del nuevo entorno.
Cómo identificar si el fallo viene de PHP, del tema o de un plugin
Antes de tocar nada, conviene disponer de una copia de seguridad de archivos y base de datos. Si el sitio es importante para el negocio, lo ideal es reproducir la incidencia en un entorno de staging o en una clonación temporal.
Checklist de diagnóstico rápido
- Confirma qué versión de PHP usa el nuevo hosting y compárala con la del entorno anterior, si la conoces.
- Revisa los requisitos de WordPress, del tema activo y de los plugins clave.
- Desactiva temporalmente todos los plugins para comprobar si el error desaparece.
- Cambia temporalmente a un tema por defecto de WordPress.
- Activa el debug y consulta
/wp-content/debug.logsi se genera. - Revisa también los logs del servidor, porque no todos los errores quedan registrados por WordPress.
Si puedes acceder al administrador, empieza por el apartado de actualizaciones. Si el backend no carga, la vía segura suele ser renombrar temporalmente la carpeta plugins por FTP o gestor de archivos para forzar la desactivación masiva. Si el sitio vuelve, ya sabes que el problema puede estar en alguna incompatibilidad php plugins o en un conflicto entre extensiones.
Después, reactiva los plugins uno a uno y prueba cada vez. Este paso permite aislar el componente exacto o, al menos, reducir el alcance del error a una función concreta: formularios, caché, seguridad, constructor visual, comercio electrónico o importación de medios.
Si con todos los plugins desactivados el fallo continúa, cambia al tema por defecto, por ejemplo uno de la serie Twenty. Si desaparece, el problema puede estar en la compatibilidad del tema, en su framework o en una integración interna con plugins específicos.
Cuando el error sigue incluso con plugins desactivados y tema por defecto, conviene mirar más allá del código de WordPress: versión de PHP del servidor, extensiones faltantes, permisos, límites de memoria, caché del hosting o reglas del servidor web.
Cómo activar el debug de WordPress y revisar los logs de errores
Para diagnosticar un fatal error php 8, activar el sistema de depuración de WordPress es uno de los pasos más útiles. Lo recomendable es registrar el error en un archivo, no mostrarlo en pantalla en producción.
En el archivo wp-config.php, conviene revisar o añadir estas líneas:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Con esa configuración, WordPress intentará registrar errores en /wp-content/debug.log. Si el archivo no aparece, no significa necesariamente que no exista un problema: puede que el error ocurra antes, que no haya permisos adecuados para escribir o que el fallo se esté registrando solo en los logs errores WordPress del servidor.
También conviene revisar el registro de errores del hosting. Según la configuración, puede estar accesible desde el panel del proveedor o mediante los logs de Apache, Nginx o PHP-FPM. Ahí suelen aparecer mensajes más útiles para localizar el archivo, la línea y el tipo de error, especialmente cuando WordPress solo muestra una pantalla en blanco o un error genérico.
- Busca referencias al plugin o tema afectado.
- Comprueba si el error menciona funciones obsoletas, parámetros incompatibles o tipos de dato no esperados.
- Verifica si hay agotamiento de memoria, tiempos de ejecución excedidos o extensiones PHP ausentes.
- Si el hosting usa PHP-FPM, revisa si el error se produce a nivel de proceso PHP y no solo dentro de WordPress.
Como referencia oficial, WordPress explica el uso de WP_DEBUG en su documentación para desarrolladores, útil para confirmar el comportamiento esperado del sistema de depuración.
Pasos para corregir incompatibilidades tras la migración
Una vez identificado el origen aproximado, toca corregir de forma ordenada. La clave es no mezclar cambios a la vez: si actualizas PHP, varios plugins y el tema en el mismo momento, luego será más difícil saber qué ha resuelto o empeorado el fallo.
- Comprueba la versión exacta de PHP. Si el nuevo hosting permite elegir versión, puede ser útil bajar temporalmente a una rama compatible con el proyecto mientras se revisan actualizaciones. Esto no debería entenderse como solución definitiva, sino como medida de diagnóstico o continuidad.
- Actualiza WordPress, tema y plugins desde fuentes fiables. Muchas incidencias aparecen porque el sitio funcionaba con software antiguo en el hosting anterior y la migración lo expone a un entorno más estricto.
- Sustituye o elimina componentes abandonados. Si un plugin no tiene mantenimiento reciente o no declara compatibilidad con versiones actuales de PHP, conviene valorar su reemplazo.
- Revisa el constructor visual o framework del tema. Algunos errores no provienen del tema base, sino de extensiones asociadas, módulos premium o integraciones incluidas.
- Vuelve a probar sin caché. Limpia la caché del plugin, del navegador y, si el proveedor la aplica, la caché del hosting o del proxy.
- Valida funciones críticas. Formularios, login, WooCommerce, envío de correos, subida de medios, cron y área de administración deberían probarse tras cada ajuste.
Si necesitas actualizar php wordpress, hazlo con criterio. En proyectos con tráfico o ventas, lo razonable es verificar antes la compatibilidad de cada componente importante. En ocasiones, el camino correcto no es subir inmediatamente a la última versión disponible, sino pasar por una versión intermedia estable mientras se completan actualizaciones del ecosistema.
Si el error afecta a una funcionalidad desarrollada a medida, conviene revisar el código personalizado. PHP 8 introduce cambios de comportamiento y controles más estrictos que pueden hacer visibles errores antiguos que antes pasaban desapercibidos.
Ajustes del nuevo hosting que conviene revisar
En una migración hosting wordpress, el servidor nuevo puede tener una configuración correcta en términos generales y, aun así, no replicar lo necesario para ese sitio concreto. Por eso merece la pena revisar varios puntos de entorno.
| Ajuste | Qué conviene revisar |
|---|---|
| Versión de PHP del servidor | Si coincide con una versión soportada por WordPress y por los componentes instalados. |
| Extensiones PHP | Si están activas las que necesita el sitio para imagen, internacionalización, compresión, XML o conexiones externas. |
| Memoria y tiempos | Límites de memoria, ejecución y subida de archivos según el uso real del proyecto. |
| Modo de ejecución | Si el hosting usa Apache, Nginx o PHP-FPM y si existen reglas o cachés que alteran el comportamiento. |
| Permisos y propietario | Si WordPress puede escribir donde necesita, por ejemplo para logs, caché o actualizaciones. |
| Correo y cron | Si las tareas programadas y el envío de emails funcionan igual que en el servidor anterior. |
También conviene comprobar si el proveedor ha activado alguna capa de optimización o seguridad que interfiera con el sitio, como reglas WAF, compresión agresiva, caché a nivel de servidor o restricciones sobre peticiones internas. Estas medidas suelen ser útiles, pero en algunos proyectos requieren ajustes finos.
Si el error visible se parece a solucionar error 500 wordpress, recuerda que el código HTTP por sí solo no identifica la causa. Puede ser un problema de PHP, de permisos, de reglas del servidor o de un fallo interno del sitio, así que lo importante sigue siendo revisar el registro de errores y reproducir el escenario de forma controlada.
Cuándo merece la pena pedir soporte técnico especializado
Hay casos en los que el diagnóstico básico no basta, especialmente si la web combina tema personalizado, WooCommerce, constructores visuales, integraciones externas o desarrollos a medida. En ese contexto, seguir probando cambios en producción puede alargar la caída o introducir nuevos problemas.
- Cuando no puedes acceder ni al backend ni a los registros del servidor.
- Cuando el error solo aparece en procesos concretos: checkout, cron, importaciones, REST API o tareas en segundo plano.
- Cuando hay mezcla de incidencias: PHP 8, caché, permisos, correo, redirecciones o HTTPS.
- Cuando el proveedor de hosting confirma que el servidor responde bien y el problema queda dentro de la aplicación.
- Cuando la web genera negocio y necesitas minimizar riesgo y tiempo de resolución.
Un soporte técnico especializado puede ayudarte a separar si el problema pertenece al código del sitio, al plugin, al tema, a la configuración de WordPress o al proveedor de hosting. Además, puede reproducir la incidencia en staging, revisar los logs con criterio y plantear una migración revisada si el cambio se hizo sin validar compatibilidades.
Como resumen práctico: si tu WordPress falla tras migrar y sospechas de PHP 8, empieza por confirmar versión, activar debug, revisar logs, desactivar plugins y probar con un tema por defecto. No hagas cambios masivos sin copia de seguridad y, si el entorno es crítico o el error no queda claro, el siguiente paso razonable es apoyarte en un diagnóstico técnico para reparar la web sin improvisar.
Si necesitas resolver una migración con incidencias, una revisión técnica bien hecha suele ahorrar tiempo frente a encadenar pruebas aleatorias, sobre todo en proyectos WordPress en producción.
Fuentes
- Documentación oficial de WordPress sobre depuración: WP_DEBUG y debug de WordPress
¿Necesitas orientación personalizada?
Te ayudamos a entender tus opciones y el siguiente paso.