Solución de problemas y errores en WordPress

Dificultad del post: facilmediadificil
[Total: 1   Promedio: 5/5]
solucionar errores wordpress

Una de las formas con las que empecé a ganarme la vida cuando me especialicé en WordPress y antes de que existiera Raiola Networks, era resolviendo problemas en WordPress y levantando webs caídas con problemas en el CMS.

Puede decirse, que, en todo este tiempo, he ganado mucha experiencia detectando rápidamente problemas al vuelo en WordPress y reparándolos de la forma más rápida posible.

solucionar errores wordpress

Hasta la versión 5.2 de WordPress, cuando existía un problema con un plugin y este causaba un error fatal en la ejecución de PHP, lo normal es que apareciera un error en la web o directamente un pantallazo en blanco, por lo que el sitio web dejaba de verse hasta que el problema era detectado y solucionado (desactivando el plugin por ejemplo).

solucionar errores wordpress

En la mayoría de casos, si el modo debug de WordPress no nos daba datos concluyentes, la solución era ir desactivando plugin a plugin desde el FTP (cambiando el nombre de la carpeta, por ejemplo) hasta dar con el plugin que estaba causando el problema.

La pantalla blanca de la muerte fue uno de los mayores miedos de los webmasters que trabajaban con WordPress, ya que como he comentado, en la mayoría de los casos buscar el problema era una tarea engorrosa y no podíamos ni acceder al panel de administración de WordPress para ver el modo debug y los errores mostrados.

A continuación, te explico algunos métodos y sistemas para conseguir detectar y determinar de dónde vienen los problemas que podemos encontrarnos en una instalación WordPress normal.

Icono suscripción Newsletter

¿Quieres
recibir mis articulos?

No te pierdas todos mis trucos para WordPress, CMS, Marketing Digital y WPO.

 

Modo recuperación en WordPress

Como he dicho, desde la versión 5.2 de WordPress se ha incorporado un modo recuperación con ciertas características que evitan que nuestro sitio web se caiga completamente cuando aparezca un error en un plugin o theme.

El funcionamiento del modo recuperación es simple, aunque no se puede forzar, para poder utilizar el modo recuperación, la instalación de WordPress debe detectar un error fatal.

Cuando el sitio web (WordPress) detecte un error falta, el visitante podrá ver este mensaje en el navegador web:

solucionar errores wordpress

Y al mismo tiempo, en el email de administrador del sitio web ha tenido que llegar un mensaje de correo electrónico con algunos datos interesantes para reestablecer el funcionamiento normal del sitio web WordPress.

solucionar errores wordpress

Al pulsar sobre el enlace que he rodeado en rojo en la captura anterior (en el email) nos activara el modo recuperación de WordPress:

solucionar errores wordpress

Nos autentificamos con los datos normales de acceso al dashboard de WordPress como administradores y podremos ver el dashboard de WordPress con dos mensajes arriba:

solucionar errores wordpress

El tema, es que WordPress ha detectado un problema grave en el código de uno de los plugins, pero en ningún momento ha dejado de servir el sitio web, sino que en su lugar cuando detecta que un administrador o usuario con permisos accede, le notifica el problema y le manda un email a la dirección de correo de administrador del sitio web.

Ahora podemos ir a la sección de plugins de WordPress y podremos distinguir bastante bien que plugins nos están dando problemas:

solucionar errores wordpress

¿Qué tenemos que hacer ahora? Pues podemos sustituir los plugins o directamente eliminarlos para que el sitio vuelva a funcionar correctamente.
La solución depende del caso y del plugin que falle, en muchos casos falla por un problema de compatibilidad con una actualización, en otros por un problema en los propios archivos del plugin, etc… pero si quieres ir a lo seguro, simplemente debes desactivar el plugin para reestablecer el servicio.

En este caso del ejemplo anterior, los errores son simplemente porque he modificado algunos archivos importantes de esos plugins modificando la sintaxis del código PHP para que no sea válido.

¿Y cuál es la razón de que WordPress hay implementado ahora este sistema? Pues en gran parte creo que es por los problemas causados por las actualizaciones automáticas implementadas en las últimas versiones de WordPress, que causaban problemas “automatizadas” en las actualizaciones de algunos plugins.

Es muy difícil mantener el control de TODOS los plugins y themes publicados en el repositorio oficial de WordPress y en casos muy exporádicos puede colarse algún plugin o theme con un problema grave que pueda dañar el funcionamiento del sitio web, de ahí el nuevo modo recuperación.

Después de utilizar el modo recuperación de WordPress, simplemente salimos o nos deslogueamos en el dashboard de WordPress para salir.

Ahora viene la gran pregunta, ¿puedo desactivar el modo recuperación de WordPress?

Pues sí, sí que puedes, ya que en algún caso puede que se active por un falso positivo o por algún problema que previamente tenemos controlado.

Para desactivar el modo recuperación de WordPress, simplemente debemos añadir la siguiente línea de código al wp-config.php de nuestro WordPress:

Con esto WordPress volverá a funcionar “normalmente” salvo que los errores causados por los plugins sean tan graves que el sitio no pueda volver a estar online sin solucionar previamente el problema.

 

Modo DEBUG en WordPress

Desde casi las primeras versiones de WordPress, el CMS trae integrado un modo debug que nos permite sacar por pantalla los mensajes de error o warnings que produce el código al ejecutarse.

modo recuperacion wordpress

Normalmente estos mensajes de error no se muestran en pantalla, ya que no quedarían bonitos para los visitantes, pero con el modo debug, al activarlo, podemos hacer que los mensajes de error aparezcan a los administradores autentificados en el sitio web.

Para activar el modo debug en WordPress simplemente debemos ir al archivo wp-config.php de la instalación de WordPress y añadir el siguiente código:

Si queremos tener el modo debug activo, pero que los mensajes no salgan por ningún lado, simplemente debemos añadir este otro código al código anterior:

Esto último es muy útil a la hora de activar el modo debug para que plugins como P3 Profiler o Query Monitor puedan funcionar correctamente, ya que necesitan el modo debug activado, pero no es necesario que se muestren los errores.
También es útil cuando solo queremos hacer logging de los errores que van apareciendo en un archivo de log, en ese caso, a lo anterior, debemos añadir el siguiente código:

Con esto se guardará un log de errores en la ruta /wp-content/debug.log que podremos consultar cuando queramos para ver que errores da nuestra instalación de WordPress.

Si no sabes cómo editar el wp-config.php de tu instalación de WordPress, te enseño en este vídeo que tengo en mi canal de Youtube:

Ten cuidado, el wp-config.php es uno de los archivos mas importantes de WordPress y un pilar fundamental en su configuración y funcionamiento.

Después de activar el modo debug, si hemos elegido mostrar los errores a usuarios autentificados como administrador, al volver a recargar la página (sobretodo en el dashboard) empezaran a aparecer los errores que tenga el sitio web al ejecutar PHP (si los hay, claro).

¿Para qué nos sirve ver los errores PHP? Pues para detectar de donde proceden y ver cómo podemos solucionarlos y en muchos casos, como hemos dicho antes, plugins relacionados con el profiling y el rendimiento también pueden necesitar acceder a las funcionalidades del modo debug de WordPress.

Por otro lado, te sorprendería conocer la cantidad de sitios web que están todo el tiempo dando error “por detrás” con el modo debug desactivado y que lo único que conseguimos al no arreglarlos es un sobreuso de recursos y en muchos casos, llegar muy rápido el archivo error_log del virtualhost o del servidor web.

 

Solucionar errores en WordPress con plugins

Como hemos explicado antes, existen plugins y/o módulos de PHP que sirven para detectar problemas en WordPress y que se apoyan en el modo debug del propio WordPress para funcionar correctamente y obtener datos.

Normalmente, estos plugins nos ayudan a detectar o determinar de donde viene un problema en WordPress de una forma, un poco más asistida o mejorada.
Aunque también existen plugins que se apoyan en módulos de PHP como XHProof para obtener datos relevantes en cuanto al profiling del código ejecutado.

¿De que plugins estamos hablando? Pues de los siguientes que vamos a detallar en este listado.

 

Query Monitor para WordPress

No vamos a entrar en profundidad en Query Monitor, ya que le he dedicado un post entero justo cuando empecé este blog hace menos de un año.

Para mí el plugin Query Monitor es una de las mejores soluciones a la hora de buscar problemas generales en la ejecución de WordPress.

Query Monitor utiliza el modo debug de WordPress para conseguir información relevante sobre la ejecución: llamadas al API, queries a la DB, slow queries, PHP ejecutado y su rendimiento, JS y CSS llamado en peticiones, etc…

modo recuperacion wordpress

Todo esto, nos lo saca a través de una interfaz bastante versátil y fácil de trabajar con ella.

En el siguiente vídeo que tengo en mi canal de Youtube, tienes un ejemplo o review de como utilizar el plugin Query Monitor en WordPress para resolver y detectar errores:

Como he dicho, no me voy a extender más hablando de Query Monitor para WordPress, ya que si quieres mas información, tan solo tienes que seguir este enlace: https://alvarofontela.com/query-monitor-solucionar-detectar-problemas-wordpress/

 

F12-Profiler para WordPress

F12-Profiler es un plugin gratuito relativamente nuevo para WordPress. Esta disponible en el repositorio de plugins de WordPress.

Una de las cosas que mas me gusta de su interfaz, es que ofrece toda la información en un solo click en cualquier parte de la web, sea donde sea.

modo recuperacion wordpress

En cada ejecución, F12-Profiler recoge datos del modo debug de WordPress y los muestra al pulsar sobre su desplegable.

F12-Profiler es especialmente útil para ver la ejecución de los plugins y las peticiones realizadas por los plugins.

Si un plugin da un timeout o alguna de las peticiones da un timeout, es muy fácil detectar de donde viene el problema, o al menos “cercar” el problema.

Puedes encontrar más información acerca de F12-Profiler para WordPress en su ficha en el repositorio de plugins de WordPress: https://es.wordpress.org/plugins/f12-profiler/

 

P3 Performance Profiler para WordPress

P3 Performance Profiler es uno de los plugins de profiling para WordPress que mas tiempo lleva en el repositorio de plugins de WordPress.

A lo largo de todo este tiempo y teniendo en cuenta que ya llevo unos años de experiencia con WordPress y con la resolución de problemas como consultor, he tenido buenas y malas experiencias con P3 Performance Profiler hasta el punto de creer en varias ocasiones que se trataba de un plugin “fake”.

modo recuperacion wordpress

Aunque lo sigo teniendo como herramienta para algunos casos, creo que los resultados que ofrece no son del todo concluyentes.

Y una de las razones por las que no ofrece resultados concluyentes (aunque creo que SIEMPRE ha fallado bastante desde el día 1) es porque lleva 4 años sin actualizaciones y pienso que aun no es compatible con PHP7 o al menos no tiene compatibilidad nativa.

Si aun quieres revisarlo, puedes encontrar más información acerca de P3 Performance Profiler en la siguiente URL en el repositorio de plugins de WordPress: https://wordpress.org/plugins/p3-profiler/

 

La mejor forma de solucionar errores

Cuando nos enfrentamos a un problema en un CMS web, la mejor forma de detectar de donde viene un problema, es ir descartando.

Personalmente creo que la experiencia es un factor muy importante a la hora de detectar y resolver problemas en WordPress de forma eficiente y rápida, sin dar vueltas buscando el problema.
Pero también es muy importante seguir una metodología, yo por ejemplo cuando no se de que puede ser, utilizo la experiencia combinada con el descarte: voy descartando elementos por intuición y sacando datos con las herramientas que tengo a mi disposición.

modo recuperacion wordpress

Lo que debemos tener en cuenta es que las herramientas van y vienen, los plugins aparecen y con el tiempo dejan de actualizarse, pero los métodos los conservamos versión a versión.

Con la aparición del modo recuperación de WordPress en la versión 5.2, muchas cosas han cambiado en el planteamiento de los errores.

Antes, un cliente llegaba a un consultor WordPress como yo con un sitio web caído o con un pantallazo blanco, ahora el cliente llega directamente con el modo recuperación activado y un email en su bandeja de entrada.
A partir de aquí, depende del cliente y de los conocimientos que tenga, aunque puedo decir que el proceso de resolución de errores causados por plugins se ha simplificado mucho con este nuevo modo recuperación.

Icono suscripción Newsletter

¿Quieres
recibir mis articulos?

No te pierdas todos mis trucos para WordPress, CMS, Marketing Digital y WPO.

Tal vez te interese...

Álvaro Fontela
Álvaro Fontela
Soy ponente en eventos de marketing digital, consultor WordPress y co-fundador de Raiola Networks, amante del mundo del motor (coches japoneses) y tecnófilo empedernido.

17 respuestas

  1. como corrijo ese error: Warning: Use of undefined constant commerce_code – assumed ‘commerce_code’ (this will throw an Error in a future version of PHP) in C:\xampp\htdocs\TECHREPAIR\wp-content\plugins\wc-transbank-webpay-plus\class-wc-transbank.php on line 127

    1. Hola Miguel, es un error muy especifico y es difícil de saber de que es exactamente sin probarlo, pero posiblemente venga por que la versión de PHP que estas usando no es compatible con el plugin que marca la ruta que has pasado.

  2. Nunca me llegó el correo de depuración, seguí una guía para configurar el correo por FTP y tampoco, el modo depuración está activado en WP_config.php pero la página sigue igual, no muestra dashboard para depurar, ya intenté de todo. 2 días antes me pasó y sólo cambié el nombre de la carpeta de plugins y desactivé el que dio el problema pero ahora pasó de nuevo y ya ni cambiando el nombre de la carpeta plugins ni la de temas sirve. Quiero pensar que alguien tuvo acceso y la echó a perder, ya se me hace mucho.
    Uso google cloud plattform para el hospedaje.

    1. Hola, pues la verdad no se que decirte, ya que no tengo mucha experiencia con Google Cloud (soy mas de Amazon AWS) y tambien depende mucho del stack que utilices.

      De todas formas, el modo recuperación de errores de WordPress esta fallando bastante, aun no lo he probado en la 5.3, pero en la 5.2 he detectado algunos fallos importantes en algunos casos, supongo que aun no estará suficientemente depurado.
      Si no te muestra el dashboard, intenta activar el modo DEBUG y activar el log de errores en archivo, para que quede registro y puedas ver que errores esta dando el sitio web.

      Un saludo.

  3. Gracias siempre por tus pedazo de contenidos, soy fan total.

    Una pregunta tonta: Si yo desactivo el modo recuperación de WordPress con la línea de código

    define(‘WP_DISABLE_FATAL_ERROR_HANDLER’, true);

    ¿En caso de un nuevo error fatal, voy a estar desactivando el hecho de que se envíe un email y me vuelva dejar acceder al backoffice? En caso de arreglar el problema que me indique (por ejemplo borrar un plugin) ¿debería ser suficiente?

    1. Hola Vir, antes de nada, gracias por tus palabras 🙂

      Te cuento, no conocía ese parámetro, pero lo he buscado y básicamente, lo que ocurriría es que…tendrías que buscar los errores al estilo «antiguo», que yo por un lado lo prefiero, el modo recuperación de WordPress en algunos casos toca mas las narices de lo que soluciona…

  4. Hola Alvaro, por favor tú gran ayuda, resulta que hoy migré mi sitio web a un nuevo Hosting, las páginas cargan correctamente excepto 2 de ellas, en la cual observo que se visualiza solo contenido pero no color de fondo, imagen de fondo , cabecera, secciones.
    He validado desactivando plugins que tenía instalado, limpieza del caché de la página y también del navegador de mi equipo local, he probado con diferentes navegadores y sigue apareciendo el mismo problema, adicional a ello, elimine la página con el fondo blanco y volví a crear una nueva arrojando el mismo error.
    Por favor me urge mucho darle solución, espero me puedas ayudar.
    Saludos

    1. Hola Sandra, sin verlo no puedo ayudarte y para eso tendría que hacerte presupuesto.

      Por eso siempre recomiendo para la gente sin experiencia que contrate hostings como Raiola Networks, que incluyen la migración de forma gratuita al contratar.

  5. Hola, quisiera saber como resablecer o restaurar los roles de wordpress, ya que soy administradora pero wordpress no me permite instalar ni desinstalar plugins, ni actualizar wordpress. además en WordPress manager en mi cpanel me sale lo siguiente:

    «Warning: The system could not load some of this WordPress site’s data. Certain sections of this interface may not function correctly.»

    (XID 9jydjx) The system failed to run the wp-cli batch commands with the following issues: Cpanel::Exception::JSONParseError/(XID tf3a5q) The system failed to parse the JSON stream data “Usage: php [options] [-f] [–] [args…] php [options] -r [–] [args…] php [options] [-B ] -R [-E ] [–] [args…] php [options] [-B ] -F [-E ] [–] [args…] php [options] -S : [-t docroot] php [options] — [args…] php [options] -a -a Run as interactive shell -c | Look for php.ini file in this directory -n No php.ini file will be used -d foo[=bar] Define INI entry foo with value ‘bar’ -e Generate extended information for debugger/profiler -f Parse and execute . -h This help -i PHP information -l Syntax check only (lint) -m Show compiled in modules -r Run PHP without using script tags -B Run PHP before processing input lines -R Run PHP for every input line -F ” for the caller “Cpanel::WordPress::WpCli::parse_json_response” because of an error: malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before «Usage: php [options]…») at /usr/local/cpanel/Cpanel/JSON.pm line 123. at /usr/local/cpanel/Cpanel/JSON.pm line 139. Cpanel::JSON::_throw_json_error(«malformed JSON string, neither tag, array, object, number, st»…, undef, SCALAR(0x369d850)) called at /usr/local/cpanel/Cpanel/JSON.pm line 123 Cpanel::JSON::Load(«Usage: php [options] [-f] [–] [args…]\x{a} php [optio»…) called at /usr/local/cpanel/Cpanel/WordPress/WpCli.pm line 197 Cpanel::WordPress::WpCli::parse_json_response(«Usage: php [options] [-f] [–] [args…]\x{a} php [optio»…) called at /usr/local/cpanel/Cpanel/WordPress/WpCli.pm line 157 Cpanel::WordPress::WpCli::__ANON__() called at /usr/local/cpanel/3rdparty/perl/528/lib/perl5/cpanel_lib/Try/Tiny.pm line 97 eval {…} called at /usr/local/cpanel/3rdparty/perl/528/lib/perl5/cpanel_lib/Try/Tiny.pm line 88 Try::Tiny::try(CODE(0x369d508), Try::Tiny::Catch=REF(0x10310a0)) called at /usr/local/cpanel/Cpanel/WordPress/WpCli.pm line 166 Cpanel::WordPress::WpCli::batch(«wp_dir», «/home/cet43457/public_html», «text», «# core version returns a string that needs special handling\x{a}#»…) called at /usr/local/cpanel/Cpanel/WordPress/Instances.pm line 372 Cpanel::WordPress::Instances::_load_expensive(HASH(0x34b2cc0), HASH(0x314b970)) called at /usr/local/cpanel/Cpanel/WordPress/Instances.pm line 304 eval {…} called at /usr/local/cpanel/Cpanel/WordPress/Instances.pm line 304 Cpanel::WordPress::Instances::get_instance_by_id(«cPanel::Blogs::WordPressX.0.1533608176») called at /usr/local/cpanel/Cpanel/API/WordPressInstanceManager.pm line 293 Cpanel::API::WordPressInstanceManager::get_instance_by_id(Cpanel::Args=HASH(0x312bde0), Cpanel::Result=HASH(0x31307c0)) called at /usr/local/cpanel/Cpanel/API.pm line 302 Cpanel::API::__ANON__() called at /usr/local/cpanel/Cpanel/API.pm line 373 eval {…} called at /usr/local/cpanel/Cpanel/API.pm line 373 Cpanel::API::_eval_guard(Cpanel::Result=HASH(0x31307c0), CODE(0x3532380)) called at /usr/local/cpanel/Cpanel/API.pm line 302 Cpanel::API::_run_module_function(Cpanel::Args=HASH(0x312bde0), Cpanel::Result=HASH(0x31307c0), «WordPressInstanceManager», «get_instance_by_id») called at /usr/local/cpanel/Cpanel/API.pm line 164 Cpanel::API::execute(«WordPressInstanceManager», «get_instance_by_id», HASH(0x3130418)) called at /usr/local/cpanel/Cpanel/API.pm line 584 Cpanel::API::run_api_mode(HASH(0x3130418)) called at uapi.pl line 308 main::script() called at uapi.pl line 139

    Agradecida de su ayuda!

  6. Hola,

    Tengo un problema con un plugins y deseo saber como desactivarlo o actualizarlo desde cPanel porque al Dashboard no puedo entrar. Gracias.

    1. Hola Yolibeth, si tu hosting no tiene ningún sistema de asistencia para WordPress como WP-CLI, no puedes hacerlo desde el panel directamente.

      Puedes desactivar plugins forzandolos al entrar a la carpeta WP-CONTENT/PLUGINS/ y cambiando el nombre de la carpeta del plugin que quieras desactivar, pero no puedes actualizarlos de esta manera.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share on twitter
Share on facebook
Share on linkedin