error php wordpress
Leer un error de PHP en WordPress: actuar rápido, sin equivocarse
Cuando un sitio WordPress se bloquea, el verdadero ahorro de tiempo consiste en leer correctamente el mensaje de error y entender a qué hace referencia: un archivo, una línea, un tipo de error (fatal, warning, notice), a veces una función o un plugin. Si corrige al azar (desactivar un plugin, restaurar un tema, vaciar las cachés), puede acertar… pero, sobre todo, corre el riesgo de empeorar la situación o de ocultar temporalmente el problema.
Un error de PHP utilizable generalmente contiene: (1) el tipo de error, (2) el mensaje, (3) la ruta del archivo afectado, (4) el número de línea, (5) y, a veces, un seguimiento (stack trace). A partir de estos elementos, puede establecer un diagnóstico fiable: conflicto de plugins, función obsoleta, archivo ausente, permisos insuficientes, memoria agotada, problema de autoload, etc.
Activar una visualización adecuada de los errores: depuración de WordPress sin exponer su sitio
El primer reflejo es activar la depuración en WordPress para obtener registros, sin mostrar los errores a sus visitantes. En un entorno de producción, mostrar los errores en pantalla es una mala idea (riesgo de revelar información sensible, deterioro de la experiencia, pérdida de confianza).
En wp-config.php, se utilizan habitualmente constantes como WP_DEBUG, WP_DEBUG_LOG y WP_DEBUG_DISPLAY. El objetivo: registrar los errores en un archivo de registro (a menudo wp-content/debug.log) y mantener la visualización pública desactivada. Este único paso transforma un fallo opaco en un incidente legible: tiene un registro fechado, a menudo con repetición de los errores, lo que ayuda a aislar la causa (una página concreta, una acción de administración, un hook activado, etc.).
Comprender los tipos de errores de PHP: fatal, de análisis, advertencia, aviso
No todos los errores tienen el mismo impacto, y tratarlos como equivalentes hace perder tiempo:
Error fatal,: Uncaught RedisException: OOM command not allowed when used memory > 'maxmemory'. en /home/clients/0945e4129de76588fab87b6f53252cc5/wordpressmaintenance/wp-content/plugins/w3-total-cache/Cache_Redis.php:150 Seguimiento de pila: #0 /home/clients/0945e4129de76588fab87b6f53252cc5/wordpressmaintenance/wp-content/plugins/w3-total-cache/Cache_Redis.php(150): Redis->setex('w3tc_2014692620...', 3600, 'a:7:{s:10:"last...') #1 /home/clients/0945e4129de76588fab87b6f53252cc5/wordpressmaintenance/wp-content/plugins/w3-total-cache/DbCache_WpdbInjection_QueryCaching.php(245): W3TC\Cache_Redis->set('afd4cf7f3f2e344...', Array, 3600, 'remaining') #2 /home/clients/0945e4129de76588fab87b6f53252cc5/wordpressmaintenance/wp-content/plugins/w3-total-cache/DbCache_WpdbNew.php(122): W3TC\DbCache_WpdbInjection_QueryCaching->query('SELECT tt.id, C...') #3 /home/clients/0945e4129de76588fab87b6f53252cc5/wordpressmaintenance/wp-includes/class-wpdb.php(3142): W3TC\DbCache_WpdbNew->query('SELECT tt.id, C...') #4 /home/clients/0945e4129de76588fab87b6f53252cc5/wordpressmaintenance/wp-content/plugins/translatepress-multilingual/includes/queries/class-query.php(910): wpdb->get_results('SELECT tt.id, C...', 'ARRAY_A') #5 /home/clients/0945e4129de76588fab87b6f53252cc5/wordpressmaintenance/wp-content/plugins/translatepress-multilingual/includes/gettext/class-gettext-manager.php(59): TRP_Query->get_all_gettext_strings('es_ES') #6 /home/clients/0945e4129de76588fab87b6f53252cc5/wordpressmaintenance/wp-includes/class-wp-hook.php(322): TRP_Gettext_Manager->create_gettext_translated_global() #7 /home/clients/0945e4129de76588fab87b6f53252cc5/wordpressmaintenance/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters(NULL, Array) #8 /home/clients/0945e4129de76588fab87b6f53252cc5/wordpressmaintenance/wp-includes/plugin.php(517): WP_Hook->do_action(Array) #9 /home/clients/0945e4129de76588fab87b6f53252cc5/wordpressmaintenance/wp-settings.php(704): do_action('init') #10 /home/clients/0945e4129de76588fab87b6f53252cc5/wordpressmaintenance/wp-config.php(99): require_once('/home/clients/0...') #11 /home/clients/0945e4129de76588fab87b6f53252cc5/wordpressmaintenance/wp-load.php(50): require_once('/home/clients/0...') #12 /home/clients/0945e4129de76588fab87b6f53252cc5/wordpressmaintenance/wp-blog-header.php(13): require_once('/home/clients/0...') #13 /home/clients/0945e4129de76588fab87b6f53252cc5/wordpressmaintenance/index.php(17): require('/home/clients/0...') #14 {main} thrown in,/home/clients/0945e4129de76588fab87b6f53252cc5/wordpressmaintenance/wp-content/plugins/w3-total-cache/Cache_Redis.php,on line,Ha habido un error crítico en esta web,Aprende más sobre el diagnóstico de WordPress,WordPress ' Error : el script se detiene en seco. El sitio puede mostrar una pantalla blanca (WSOD) o un mensaje de error crítico. A menudo está relacionado con una función inexistente, una clase no encontrada, falta de memoria, un archivo ausente o una incompatibilidad con PHP.
Error de análisis \/ error de sintaxis : PHP no puede interpretar el archivo (a menudo falta una llave, se ha olvidado un punto y coma o hay una coma final). Es frecuente después de copiar y pegar código en functions.php o un archivo de plugin.
Advertencia : el código continúa, pero algo no funciona (include imposible, argumento no válido, división por cero, etc.). Hay que vigilarlo: una advertencia repetida puede ralentizar un sitio o anunciar un futuro error fatal.
Aviso : problema menor (variable no definida, índice ausente). A menudo no tiene consecuencias inmediatas, pero un sitio bien mantenido los reduce, porque señalan una calidad del código mejorable y pueden romper salidas HTML o JSON en determinados contextos.
Dónde encontrar los errores: administración, registros del servidor, debug.log, pantalla crítica
Según la configuración, puede aparecer un error de PHP:
En la interfaz de WordPress, con el mensaje «El sitio ha encontrado un error crítico», a veces acompañado de un correo electrónico automático de WordPress que menciona la extensión responsable.
En el archivo wp-content/debug.log si el registro está activado.
Más información sobre nuestros servicios de mantenimiento de sitios WordPress
En los registros del servidor (Apache\/Nginx\/PHP-FPM). Estos registros suelen ser más completos y también revelan errores no gestionados por WordPress.
En herramientas de monitorización (si dispone de ellas), útiles para correlacionar un error con un pico de tráfico, una actualización o una tarea cron.
Interpretar la ruta y la línea: el GPS de su diagnóstico
Cuando el mensaje indica un archivo del tipo \/wp-content\/plugins\/mon-plugin\/..., la probabilidad es alta de que el plugin sea la causa (o que sea la víctima de otro problema, pero es un punto de partida). Si la ruta apunta a \/wp-content\/themes\/mon-theme\/..., prioricen el tema o un tema hijo. Si ven \/wp-includes\/ o /wp-admin/, el error suele proceder de una llamada realizada por un plugin\/tema, pero se manifiesta en el núcleo de WordPress.
El número de línea sirve para localizar con precisión la instrucción. Es muy útil para detectar una función obsoleta, un tipo incorrecto pasado a una función o un acceso a un índice que no existe. Atención: la línea mencionada no siempre es el origen lógico del error, sino el punto en el que PHP ya no puede continuar.
Caso n.º 1: pantalla blanca (WSOD) o There has been a critical error on this website
En este escenario, es muy probable que se trate de un error fatal. El método más eficaz consiste en:
1) Leer el correo electrónico del error crítico (WordPress suele enviar uno al administrador).
2) Consultar el debug.log o los registros del servidor.
3) Desactiva temporalmente la extensión indicada o vuelve a un tema predeterminado.
Si ya no tienes acceso al panel de administración, utiliza FTP\/SFTP y cambia el nombre de la carpeta del plugin problemático (por ejemplo, mon-plugin en mon-plugin.off): WordPress lo desactivará automáticamente. La misma técnica sirve para un tema (forzando a WordPress a volver a un tema disponible).
Para seguir un proceso estructurado, puedes consultar una checklist de solución de problemas paso a paso como Solucionar problemas de WordPress: procedimiento en 10 pasos, útil para no olvidar nada (caché, extensiones, tema, configuración, etc.).
Caso n.º 2: errores después de una actualización (core, plugin, tema)
Una gran parte de los errores de PHP aparecen justo después de una actualización: una extensión deja de ser compatible con su versión de PHP, un tema espera una función de un plugin o un plugin utiliza una API de WordPress modificada. Los síntomas típicos: fatal error por una clase no encontrada, warnings inéditos o acceso al área de administración imposible.
Los buenos reflejos: identificar qué ha cambiado, volver temporalmente atrás si es necesario (rollback controlado) y después actualizar todo (core, plugins, tema) con una combinación compatible. Si gestiona este tipo de incidentes con frecuencia, tenga preparado un procedimiento específico: Problema de actualización: qué hacer.
Caso n.º 3: Allowed memory size exhausted (memoria PHP insuficiente)
Este error es frecuente en sitios que crecen: builder, plugins grandes (SEO, comercio electrónico, copias de seguridad), importaciones o un back-office cargado. Indica que PHP ha alcanzado el límite de memoria permitido. La solución puede ser:
Aumentar la memoria (si el alojamiento lo permite) y alinear los parámetros (límite de memoria de PHP, límite de memoria de WordPress).
Reducir el consumo: desactivar un plugin que consuma demasiados recursos, sustituir una extensión, optimizar las consultas y limitar las operaciones pesadas en el área de administración.
Comprobar el alojamiento: un hosting compartido limitado puede provocar errores en cuanto un proceso supera las cuotas.
Para evitar tratar el síntoma sin solucionar la causa, es útil optimizar todo (caché, autoload, plugins, medios), especialmente si utiliza un hosting compartido: Optimizar en un alojamiento compartido.
Caso n.º 4: errores 500 y bloqueos del lado del servidor
Un error 500 (Internal Server Error) no es un error de PHP en sentido estricto, pero puede deberse a un fallo de PHP, a una configuración del servidor, a un archivo .htaccess dañado, a límites alcanzados o a un plugin que entra en bucle. A menudo, WordPress no tiene tiempo de mostrar un mensaje detallado: hay que leer los registros del servidor.
Las causas habituales son: reglas de reescritura no válidas, permisos de archivos incorrectos, límites de memoria/tiempo de espera, conflicto de caché o una actualización interrumpida. En caso de duda, un recurso específico puede orientarle sobre las posibles causas concretas de este tipo de fallo: Error 500 de WordPress: asistencia, solución de problemas y ….
Caso n.º 5: Error establishing a database connection y errores relacionados con MySQL
Este error puede aparecer sin un mensaje de PHP explícito, pero a menudo provoca una indisponibilidad total. Puede deberse a: credenciales de la base de datos incorrectas en wp-config.php, un servidor MySQL caído, una base de datos dañada, un número excesivo de conexiones o un alojamiento saturado.
El diagnóstico correcto consiste en comprobar primero la disponibilidad del servidor de base de datos y las credenciales, después el estado de la base de datos (tablas, reparación, espacio en disco) y, por último, la carga global del servidor. Para consultar un procedimiento detallado orientado a la resolución, puede consultar Cómo resolver el error de conexión a la base de datos ….
Caso n.º 6: Parse error: syntax error después de modificar el código
Más información sobre nuestros servicios de mantenimiento de sitios WordPress
El escenario clásico: añadir un snippet en functions.php (o un plugin de snippets), y el sitio deja de estar accesible inmediatamente. La corrección suele ser sencilla:
Volver al archivo modificado mediante FTP\/SFTP, localizar la línea y corregir la sintaxis (llaves, paréntesis, comillas, punto y coma).
Evitar la edición directa en producción: priorizar un entorno de staging o, como mínimo, un plugin de snippets que pueda desactivar un código problemático sin romper todo el sitio.
Utilizar un editor con validación sintáctica y autoformateo para limitar los errores.
Caso n.º 7: funciones obsoletas e incompatibilidades de versión de PHP
Una actualización de PHP (p. ej., pasar a 8.x) suele mejorar el rendimiento y la seguridad, pero puede romper un plugin antiguo. Los mensajes típicos son: Deprecated, Uncaught TypeError, Call to undefined function o errores de tipado estricto. En ese caso:
Actualizar el plugin\/tema a una versión compatible.
Reemplazar la extensión si ya no recibe mantenimiento.
Evitar los temas propios no probados: si se necesita código personalizado, documentarlo y probarlo en staging.
Aislar la causa: método de triaje fiable (sin pasar el día en ello)
Cuando no se sabe de dónde proviene el error, aplicar un método de triaje:
1) Reproducir : ¿qué URL, qué acción, qué rol de usuario, qué navegador? Un error aleatorio suele ser un error no reproducido.
2) Leer el primer error : en un registro, la primera aparición suele ser la causa; las siguientes son consecuencias en cadena.
3) Desactivar por lotes : si el registro apunta a un plugin, empezar por él. Si no, desactivar todos los plugins y volver a activarlos uno a uno. Es largo, pero es determinista.
4) Volver a un tema predeterminado : para eliminar los problemas del tema.
5) Verificar las cachés : caché del plugin, caché del servidor, CDN. Un archivo obsoleto puede mantener un error aunque el código se haya corregido.
6) Verificar los límites del servidor : memoria, tiempo de espera, tamaño de carga, número de procesos.
Corregir correctamente: parche mínimo y luego protección
Una corrección eficaz se realiza en dos etapas. Primero, un parche mínimo para volver a poner el sitio en marcha (desactivar la extensión defectuosa, revertir cambios, corrección sintáctica). Después, una seguridad : actualización, sustitución de extensión, pruebas, adición de salvaguardas (staging, copias de seguridad, monitorización).
Si interviene en código, evite los quick fixes que ocultan el error (p. ej., añadir unos @ delante de funciones, desactivar los logs o ignorar los warnings). Es mejor corregir el origen: validación de argumentos, comprobación de existencia (función\/clase), compatibilidad con PHP y respeto de los hooks de WordPress.
El papel del alojamiento: rendimiento, estabilidad y errores de PHP
Muchos errores repetitivos (timeouts, memoria, errores 500) se agravan por un servidor con recursos insuficientes o mal configurado. Un alojamiento demasiado limitado puede convertir un simple warning en una caída recurrente en cuanto llega un pico de tráfico. Por el contrario, una infraestructura adecuada (PHP-FPM configurado, recursos suficientes, almacenamiento rápido, versión de PHP mantenida) reduce drásticamente los incidentes.
Si se plantea cambiar de servidor o contratar un plan superior, apóyese en criterios concretos (recursos, aislamiento, soporte, copias de seguridad, logs, versiones de PHP\/MySQL, política de seguridad): y Alojamiento Cómo Elegir un Servidor de Alto Rendimiento.
Documentar para corregir más rápido la próxima vez
Los errores de PHP nunca son un episodio aislado: vuelven a aparecer de otra forma si el sitio crece, si cambia el equipo o si evoluciona la stack. Documentar su WordPress (plugins críticos, ajustes del servidor, snippets, procedimientos de actualización, accesos, diagramas funcionales) reduce considerablemente el tiempo de resolución.
La documentación útil no es una novela: debe ayudar a responder rápidamente a ¿qué se ha cambiado?, ¿dónde está el código personalizado?, ¿cuáles son los plugins indispensables?, ¿cómo restaurar?. Para estructurar este aspecto, puede apoyarse en Cómo documentar su sitio para mantenerlo mejor.
Cuando reparar se convierte en un proyecto: restauración, limpieza, puesta a punto
A veces, corregir un error de PHP revela una situación más amplia: acumulación de plugins, temas obsoletos, exceso de código personalizado, base de datos inflada, permisos de archivos incoherentes. En ese caso, reparar no se limita a corregir una línea: hay que devolver el sitio a un estado mantenible (copia de seguridad, auditoría, limpieza, actualización, pruebas, refuerzo de la seguridad).
Más información sobre nuestros servicios de mantenimiento de sitios WordPress
Si busca un marco de reparación más global (más allá del simple mensaje de error), un enfoque paso a paso puede ayudar: ¿Cómo reparar un sitio WordPress?.
Prevenir en lugar de sufrir: mantenimiento, pruebas, copias de seguridad, monitorización
La mejor corrección sigue siendo la que no tiene que hacer con urgencia. Un mantenimiento regular limita considerablemente los errores de PHP: actualizaciones controladas, pruebas en staging, copias de seguridad verificadas, supervisión de los registros, rotación de las versiones de PHP y revisión periódica de las extensiones. Para una pyme, el objetivo es sencillo: evitar la interrupción de la producción, proteger los ingresos y mantener un sitio eficiente y seguro.
Si su sitio respalda objetivos de negocio (leads, comercio electrónico, reservas de citas), es conveniente definir qué es realmente indispensable a largo plazo: Mantenimiento para PYMES Lo Que Es Indispensable.
¿Cuándo confiar la corrección a un servicio de mantenimiento de WordPress?
Puede corregir usted mismo parte de los errores si tiene acceso a los registros, a un FTP\/SFTP y un mínimo de método. En cambio, es preferible delegar si: el error es recurrente, el administrador es inaccesible, tiene requisitos de disponibilidad, carece de copias de seguridad fiables o sospecha de un problema del servidor (recursos, base de datos, configuración).
Un servicio de mantenimiento suele aportar: monitorización, copias de seguridad, actualizaciones probadas, intervenciones rápidas y, sobre todo, una reducción del riesgo de que se produzca un incidente crítico en el peor momento. Si quiere establecer una solución recurrente en lugar de gestionar las urgencias caso por caso, puede descubrir nuestras ofertas de mantenimiento.
Conclusión: un error de PHP se lee, se demuestra y luego se corrige
Para corregir eficazmente, parta de los hechos: mensaje exacto, archivo, línea, contexto de reproducción y registros. Vuelva a poner el sitio en línea con un parche mínimo y, después, estabilícelo: actualizaciones coherentes, alojamiento adecuado, documentación y mantenimiento continuo. Esta disciplina transforma las averías incomprensibles en incidentes controlados, más rápidos de resolver y mucho menos costosos.
