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.
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).
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.
¿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:
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.
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:
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:
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:
¿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:
| 1 | define('WP_DISABLE_FATAL_ERROR_HANDLER', true); |
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.
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:
| 1 | define('WP_DEBUG', true); |
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:
| 1 | define('WP_DEBUG_DISPLAY', false); |
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:
| 1 | define('WP_DEBUG_LOG', true); |
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…
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.
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”.
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.
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.
¿Quieres
recibir mis articulos?
No te pierdas todos mis trucos para WordPress, CMS, Marketing Digital y WPO.
40 Responses
Excelente Artículo y muy util.
Soy algo nuevo en esto de Wordpress, pero vamos aprendiendo.
Muchas gracias!
De eso se trata Crisanto, de aprender todos los días 🙂
Hola, sabes que lelgué aquí buscando la solución a éste error
Hubo un error al recuperar tus mensajes. Por favor, inténtalo de nuevo.
y lo otro que se queda pegado al guardar los cambios de páginas.
Sabrás a que se puede deber?
Saludos y muchas gracias
Hola Rosa, intuyo que “Hubo un error al recuperar tus mensajes. Por favor, inténtalo de nuevo.” te sale en WooCommerce.
Creo que ambos problemas que tienes pueden estar relacionados con un problema de javascript en algun plugin, puede ser porque “imponga” una versión de jQuery no compatible o directamente por una incompatibilidad de algun tipo.
Tampoco es algo fijo, pero me huele que el problema venga por ahi.
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
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.
Me sale este error en la pagina podria ser por la version de php que estoy usando?
Notice: ob_end_flush(): failed to send buffer of zlib output compression (1) in /home/yatesito/public_html/wp-includes/functions.php on line 4979
Hola Rodolfo, tienes dos opciones:
– Desactivar zlib.output_compression en tu hosting o servidor.
– Probar con esto: https://stackoverflow.com/questions/38693992/notice-ob-end-flush-failed-to-send-buffer-of-zlib-output-compression-1-in
Me ayudo a resolver un problema que tenia desde hace un dia, gracias por la información
Gracias a ti Cesar 🙂
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.
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.
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?
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…
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
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.
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!
Hola, este plugin posiblemente te ayude si has modificado los roles (el de administrador sobretodo) y te ha ocurrido eso: https://wordpress.org/plugins/reset-roles-and-capabilities/
El error que me comentas es por el WP-CLI que esta usando tu proveedor de hosting para el WordPress Manager, esta dando error por los permisos del usuario admin.
Oka, Muchas gracias!
Hola,
Tengo un problema con un plugins y deseo saber como desactivarlo o actualizarlo desde cPanel porque al Dashboard no puedo entrar. Gracias.
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.
Hola Álvaro, sólo quiero agradecerle su ayuda y dirección ya que gracias a su guia pude resolver el problema y aprender.
Saludos.
Gracias a ti Yolibeth por leerme 🙂
Qué puedo hacer. Si no puedo acceder al cpanel me es imposible arreglar algo. Qué podrá ser eso? Además, no me ha llegdo ningún correo. Estoy de manos atadas en esto
Hola Yosvani, si no puedes entrar a cPanel tienes que contactar con tu hosting para que te digan que esta pasando, ya que puede ser que el servidor este caído directamente.
Hola buen dia
Mi sitio web funciona perfectamente pero no me deja acceder al escritorio. Me dice que ha habido un error crítico. Ya probe renombrando la carpeta de plugins y tambien la de themes y nada.
este ess el error que recibo
“Ha habido un error crítico en esta web. Por favor, comprueba la bandeja de entrada del correo electrónico del administrador de tu sitio para obtener instrucciones”
Sin embargo, en mi bandeja de entrada no hay ningún correo de wordpress.
Aprovecho de comentarte, que desde hace algun tiempo ya no me permitía ingresar con /wp-admin sino que debia hacerlo con /wp-login.
Habrá alguna forma de hacer que wordpress reenvie el correo?
Muchas gracias por lo que puedas ayudarme
Hola Elianne, tu problema solo hay una forma de solventarlo y ver que esta pasando.
Si no te llega email, puede ser un error mas grave. Tienes que activar el modo debug en el wp-config.php y ver que errores salen en pantalla, o también puedes registrarlos en un archivo.
Si no tienes conocimientos, puedes necesitar un consultor que te lo haga, ya que no es fácil.
Hola Alvaro, estoy intentando entrar mi usuario de WP y cuando ingreso no me aparece mi sitio web creado. Cuando intento entrar desde el sitio web con el /admin o /wp-login.php me dice Page Not Found. Agradezco tu ayuda para solucionar este problema.
Hola Agustin, con tan pocos datos es muy difícil decirte nada, puede ser un problema de rewrites, aunque normalmente no afectan al /wp-admin.
También puede ser que hayas cambiado la ruta de login por seguridad y ahora no te acuerdes, ya que es lo único que se me ocurre.
Gracias, estaba buscando como solucionar ese error, me apreció al querer activar woocommerce, el sitio sigue funcionando bien, pero no me deja activar woocommerce. Espero poder solucionarlo.
Hola Fabiola, puede ser por múltiples cosas, desde un conflicto de plugins, hasta un problema en el campo active_plugins de la tabla wp_options en la DB de WordPress.
Hola amigos me sale este error en Woocomerce no se porque: “Hubo un error al recuperar tus mensajes. Por favor, inténtalo de nuevo.” se queda cargando la website :/
Hola Beto, con tan pocos datos no te puedo ayudar.
Si necesitas ayuda profesional para solucionar el problema, envíame un email desde el form de contacto de esta web: https://alvarofontela.com/contacto/
Hola, muchas gracias por tu contenido, instalé este plugging woo button text y de pronto ya no funciona nada, no se ve el sitio,
Esto es lo que aparece Notice: Trying to access array offset on value of type bool in /home2/ (mi dirección)
Ni puedo administrarlo, entro vía FTP y no tengo nada, y no me llega el correo de recuperación de wordpress ¿Hay algo extra que me recomiendes? Mil gracias
Hola Guadalupe, pues…con tan pocos datos y encima tan contradictorios no puedo decirte nada concluyente.
Es decir, si metes un plugin, es imposible que te hayan desaparecido los archivos del FTP, son cosas completamente diferentes y problemas aislados. De hecho, si te sale el “Notice:” es imposible que el FTP este vacío.
Creo que deberías contactar con tu proveedor de hosting.
Hola Álvaro, cuando accedo a mi página de inicio de mi web no tengo problemas pero cuando quiero acceder a cualquiera de las páginas que tengo creadas se pone la pantalla en negra completamente con una “X” de color blanca arriba a la derecha. Esta X no está activa.
Podrías decirme que tengo que hacer? gracias
Hola Maria Jose, lo que comentas no es un error típico de WordPress, sin verlo no puedo decirte nada concreto. Puede ser desde javascript hasta de hooks.
Hola Alvaro,
Unauthorized Activity Detected
You are seeing this page because we have detected unauthorized activity.
If you believe that there has been some mistake,
Click here to e-mail our website-security team and describe your case.
Case Number: 87927386
Me sale este error cuando le doy en modificar ciertas paginas de mi wordpress, a que crees que se deba eso. El usuario que modifica si es el de administrador.
Hola Cristian, lo siento, desconozco de que plugin o sistema de seguridad es ese mensaje, nunca lo he visto.
Hola alvaro tenia un problema en wordpress me dijo en pantalla blanca, revisando varios temas me dijo que descargara file manager y cambiara pluguis po pliguin y temas por temas2 al hacer esto me borro todos los temas y pluguins y no me deja descargar nada ni hacer nada, el sitio quedo con este error.
The theme directory “white-nina” does not exist.
Error: The themes directory is either empty or doesn’t exist. Please check your installation.
no puedo instalar nada y en temas aparece
false
Si me pudieras dar una ayuda gracias