La pantalla blanca de la muerte de WordPress: una guía para la recuperación
Publicado: 2023-01-10WordPress, como MacOS e incluso Windows ahora, tiene una infame "Pantalla blanca de la muerte" o "WSOD" para abreviar. El WSOD aparece cuando algo sale muy mal. Te enfrentas a una pantalla blanca en blanco o en su mayoría en blanco por razones desconocidas. ¿Ahora que?
¿Qué es la pantalla blanca de la muerte de WordPress (WSOD)?
Es poco probable que encuentre la "Pantalla blanca de la muerte" (WSOD) en un sitio de WordPress en condiciones normales. Es simplemente una pantalla blanca en blanco que aparece en lugar de la interfaz pública de un sitio de WordPress. Significa que WordPress se ha bloqueado y no se cargará correctamente.
La Pantalla Blanca de la Muerte es probablemente el resultado de algo USTED le hizo a su sitio de WordPress.
¿Por qué? ¿Qué ha ido mal?
Desde que se lanzó WordPress 5.2 en mayo de 2019, WordPress ha tenido un modo de recuperación para protegerlo del WSOD. Sin el modo de recuperación, los problemas de compatibilidad generarían muchos WSOD y frustrarían a los usuarios de WordPress. Si su servidor usa una versión de PHP o MySQL que no es compatible con un complemento, tema o extensión que está instalando, en lugar de romper su sitio, obtendrá el modo de recuperación. Hoy en día, un error PHP Out-of-Memory (OOM) es probablemente el escenario restante más común que omitirá la protección WSOD, dejándolo con una pantalla totalmente en blanco.
Verifiqué con el colaborador principal de WordPress, Marius Jensen, para averiguar qué más podría causar un verdadero WSOD en la actualidad. Marius es el autor del complemento Site Health (ahora Health Check and Troubleshooting) cuyo concepto y características finalmente se incorporaron al núcleo de WordPress. (Así es como obtuvimos el modo de recuperación y otras protecciones). Marius confirmó que la única forma de hacer que WordPress se bloquee con una pantalla totalmente en blanco es interrumpir el flujo de ejecución de PHP para que el controlador de errores fatales no pueda funcionar como debería. Romper la conexión entre PHP y su servidor HTTP lo logrará. No recibirá ningún comentario de solución de problemas en pantalla. Eso sería frustrante, pero si simplemente está trabajando dentro de WordPress, instalando y configurando complementos, es poco probable que esto suceda.
¿La pantalla blanca de la muerte significa que WordPress ha sido pirateado?
No, un WSOD no significa que los malos te atraparon. Sin embargo, en casos excepcionales, podría ser un efecto secundario de una brecha de seguridad. Si cree que los piratas informáticos han comprometido su sitio, diríjase a la guía de Kathy Zant, Cómo limpiar un sitio de WordPress pirateado.
Un error de codificación de PHP, un conflicto entre dos o más complementos o un problema en el entorno de su servidor son las causas más probables de un WSOD. ¡Afortunadamente, estas no son catástrofes! Su sitio y su contenido no se han perdido. Si lo desea, puede arreglar un WSOD usted mismo.
En este artículo, repasaremos la lista de posibles diagnósticos y curas para el WSOD. Aprenderá cómo hacer que su sitio de WordPress vuelva a la vida. También aprenderá cómo funciona WordPress en un nivel más profundo.
Ver vista previa
La pantalla blanca de la muerte de WordPress: ¿Hice eso?
Sí. La Pantalla Blanca de la Muerte es probablemente el resultado de algo USTED le hizo a su sitio de WordPress.
La causa de un WSOD generalmente se encuentra en un complemento de WordPress que acaba de instalar y activar. O bien, podría ser el resultado de una actualización reciente. Un complemento recién agregado o actualizado puede estar en conflicto con otro complemento. En este escenario, un complemento está tratando de hacer lo mismo que otro, o están actuando con propósitos contradictorios.
Si un complemento, un tema o fragmentos de código PHP que funcionan mal están causando un error fatal, es posible que obtenga un WSOD. Pueden contener un error de sintaxis, un error o un código que no es compatible con la versión de PHP que está utilizando. Si usted o su anfitrión acaban de actualizar su versión de PHP, ¡lo cual es bueno! — Los complementos incompatibles comenzarán a arrojar errores y podrían derribar su sitio con un WSOD. Si está utilizando WordPress 5.2 o superior como debería, los problemas de incompatibilidad activarán el modo de recuperación, que es mucho más útil que un verdadero WSOD.
Por lo general, el culpable es lo que se acaba de cambiar con un complemento, un tema o un código personalizado.
Dado que el WSOD es a menudo una respuesta a lo que se cambió por última vez (o muy recientemente) que afecta la funcionalidad de su sitio. Revisa todos los cambios recientes. Concéntrese en los cambios que parezcan más probables de causar un problema. Si acaba de instalar un nuevo complemento o modificó algún código de tema, esos son los primeros lugares para buscar para ver qué podría haber salido mal.
Cuando WordPress solo está mayormente muerto
Todos los WSOD no son iguales, y algunos ni siquiera son verdaderos WSOD.
Es posible que reciba algún tipo de mensaje de error en lugar de una pantalla completamente blanca. Puede ser un mensaje de error del servidor sobre un error HTTP 500 o una conexión de base de datos perdida. Puede ser un mensaje de error crítico de WordPress. O bien, su sitio puede cargarse normalmente para los visitantes, pero cuando intenta iniciar sesión, obtiene la pantalla blanca de la muerte. Lo contrario puede ser cierto en otros casos: puede iniciar sesión en el panel de control de WordPress, pero la parte frontal pública de su sitio les da a todos una pantalla en blanco.
Si su experiencia en la WSOD se ajusta a alguna de estas descripciones, ¡buenas noticias! Su sitio solo está mayormente muerto. No será difícil revivirlo.
Si se encuentra frente a una pantalla blanca completamente en blanco cuando visita su sitio de WordPress o intenta iniciar sesión, ese es el verdadero WSOD. Tendrás que profundizar un poco más para determinar qué lo está causando.
Modo de recuperación de WordPress y la pantalla blanca de la muerte
Afortunadamente para cualquiera que se enfrente a un WSOD, el modo de recuperación se introdujo en WordPress 5.2 para eliminarlo. El modo de recuperación detecta muchos errores fatales y lo ayuda a corregirlos. Si no está utilizando la versión principal más reciente del núcleo de WordPress, comience allí. ¡Ponte al día!
Gracias al modo de recuperación de WordPress, es raro ver una pantalla blanca completamente en blanco cuando algo sale mal. Verás más a menudo una ventana blanca sobre una pantalla gris con el siguiente mensaje a partir de WordPress 6.1:
Las versiones anteriores de WordPress mostrarán mensajes redactados de manera similar, como "El sitio está experimentando dificultades técnicas".
Si navega a una URL de backend /wp-admin , también habrá un aviso que le indicará que verifique su cuenta de correo electrónico de administrador para obtener más información:
En otros casos, es posible que vea una pantalla blanca con texto en negrita que describe un "Error interno del servidor" con algún tipo de explicación y orientación para reparar su sitio.
Bienvenido a Recuperación
Este es el modo de recuperación. WordPress está tratando de ayudarlo a ayudarlo a recuperarse.
Lo primero que debe hacer es verificar la dirección de correo electrónico asociada con su cuenta de administrador de WordPress. WordPress intenta identificar errores fatales de PHP en todo el código que ejecuta.
Si es posible, WordPress "pausará" un complemento u otro código que no funcione correctamente. WordPress evitará que se ejecute el código incorrecto. Luego informará los detalles a los administradores por correo electrónico.
En el correo electrónico del modo de recuperación, encontrará instrucciones y un enlace temporal para iniciar sesión en WordPress en modo de recuperación. (Este enlace es válido durante 24 horas. Después de eso, se enviará uno nuevo si el sitio aún experimenta un error crítico).
SUGERENCIA PROFESIONAL: Si no recibe el correo electrónico del modo de recuperación, es posible que pueda iniciar sesión en WordPress en el modo de recuperación de todos modos agregando la siguiente dirección a la URL de su sitio base cuando inicie sesión como administrador: /wp-login.php?action=entered_recovery_mode .
Aquí está su oportunidad de investigar más a fondo. Si el modo de recuperación ha identificado un complemento específico como la causa de su WSOD, desactívelo. Esto hará que su sitio vuelva a estar disponible para todos. Luego puede investigar cualquier problema conocido para este complemento. Compruebe si hay una actualización para ello. Comuníquese con las personas responsables de su mantenimiento.
No todas las pantallas blancas de la muerte son iguales en WordPress
En algunos casos excepcionales, algo salió mal en otro lugar de WordPress o en el entorno de su servidor. Es posible que un proceso de actualización o instalación se haya estancado, dejando su sitio atascado en modo de mantenimiento. Es posible que usted, su proveedor de alojamiento o un complemento que haya instalado hayan modificado los archivos php.ini o .htaccess con resultados inesperados. Es posible que su entorno existente no admita los requisitos de un complemento recién instalado.
El modo de recuperación de WordPress no puede hacer frente a estas situaciones, pero producirá mensajes de error visibles en una pantalla que de otro modo sería blanca. Es posible que no se pueda acceder al front-end de su sitio, pero es posible que la pantalla de inicio de sesión del administrador y la interfaz de back-end funcionen con normalidad.
Estas no son situaciones reales de WSOD, pero son igual de molestas. Por lo general, una de las siguientes condiciones los causa:
1. Estás atascado en el modo de mantenimiento
Al actualizar el núcleo, los complementos o los temas de WordPress, WordPress entra en "Modo de mantenimiento". Navegar a cualquier parte del sitio mostrará una pantalla gris con una ventana de mensaje blanca que dice:
A veces, esto no se resuelve en un minuto, pero el alojamiento de WordPress con gestión de calidad lo notará y lo solucionará con un proceso automatizado. Si ha esperado unos minutos sin cambios, puede salir del modo de mantenimiento eliminando el archivo .maintenance en la carpeta raíz de su aplicación/web donde está instalado WordPress. (Para verlo, es posible que deba habilitar la visualización de archivos "invisibles" encabezados por un punto en el nombre del archivo).
Cuando no haya un archivo .maintenance presente, su sitio se cargará como se esperaba.
2. Ha alcanzado un límite de carga de archivos o tamaño de publicación
Es posible que se agote el tiempo de espera de su sitio y aparezca una pantalla en blanco en un proceso de carga, publicación posterior o envío de formularios porque está enviando demasiados datos.
Solución: aumente el límite de contenido de su publicación en wp-config.php :
ini_set('pcre.recursion_limit',20000000);
ini_set('pcre.backtrack_limit',10000000); Solución: aumente la carga de archivos y el límite de tamaño de publicación en php.ini :
upload_max_filesize = 256M post_max_size = 256M
Extender el tiempo (en segundos) antes de que se agote el tiempo de espera de una publicación o de cualquier envío de formulario también puede ayudar. También es posible que aumente el tiempo que PHP tiene para ejecutar scripts y analizar la entrada. Además, podemos aumentar la cantidad de variables que se permiten en el envío de un formulario. Finalmente, podemos especificar el límite de tiempo después del cual PHP tratará los datos enviados como basura:
max_execution_time = 300 max_input_time = 300 max_input_vars = 1000 sesión.gc_maxlifetime = 1000
O en .htaccess , httpd.conf o virtualhost :
php_value upload_max_filesize 256M php_value post_max_size 256M php_value max_execution_time 300 php_value max_input_time 300 php_value max_input_vars 1000 php_value sesión.gc_maxlifetime 1000
O en un fragmento de código personalizado para WordPress o un archivo functions.php de tema:
@ini_set( 'upload_max_filesize', '256M' );
@ini_set( 'post_max_size', '256M' );
@ini_set('max_execution_time', '300');
@ini_set('max_input_time', '300' );
@ini_set('max_input_vars', '1000' );
@ini_set('sesión.gc_maxlifetime', '1000' );Los valores de memoria y tiempo en estos parámetros son solo recomendaciones. Para asegurarse de que estén funcionando y verificar sus valores actuales, use la herramienta Salud del sitio en su interfaz de administración de WordPress.
Junto con el modo de recuperación, WordPress 5.2 introdujo la herramienta Salud del sitio. Es muy útil para diagnosticar problemas y obtener información técnica sobre la configuración de su sitio y el entorno del servidor. Encuéntrelo en su Menú de administración en Herramientas > Estado del sitio. También puede beneficiarse de las funciones ampliadas en el complemento Health Check and Troubleshooting para WordPress.
3. PHP no tiene memoria
PHP es el lenguaje de secuencias de comandos del lado del servidor en el que se basa el núcleo de WordPress. Aparece un WSOD si no hay suficiente memoria para que PHP ejecute WordPress y sus complementos activos. Es posible que vea esto indicado en un mensaje de error o en un registro.
Dependiendo de su plan de alojamiento, puede aumentar el límite de memoria PHP para todas las aplicaciones en su servidor o una instancia específica de WordPress. Pida ayuda al equipo de soporte técnico de su host si no está seguro de qué hacer.
wp-config.php
Normalmente, agregar la siguiente configuración a su archivo wp-config.php en su carpeta de WordPress establecerá el límite de memoria frontal para WordPress en 256 MB en este ejemplo:
define('WP_MEMORY_LIMIT', '256M'); 128 a 256 MB deberían ser más que adecuados. También puede definir la memoria máxima o de back-end asignada a PHP (256 MB también en el siguiente ejemplo) agregando la siguiente línea a wp-config.php también:
define('WP_MAX_MEMORY_LIMIT', '256M');El segundo número es el límite máximo de memoria que define la memoria total que PHP tiene disponible para sí mismo. El primer número es la memoria para WordPress que se ejecuta dentro de ese límite de PHP más grande. El límite máximo de memoria de PHP debe ser igual o mayor que el límite de memoria de la aplicación de WordPress.
php.ini
Otra forma de definir el límite máximo de memoria de PHP es con una configuración en un archivo php.ini ubicado en su carpeta de WordPress:
límite_memoria = 256M
¡Asegúrese de que no haya punto y coma al comienzo de la línea! Y tome nota, php.ini solo afectará la instancia de WordPress (o cualquier otra aplicación PHP) que se ejecute en o debajo de la carpeta en la que se encuentra el archivo php.ini . Si tiene acceso a su servidor o raíz web, un php.ini ubicado allí regirá la configuración ambiental para todas las aplicaciones PHP a menos que tengan su propio archivo php.ini que especifique condiciones diferentes.
.htaccess
Una tercera forma de definir el límite de memoria de PHP es a través del archivo .htaccess en su carpeta de WordPress si está utilizando Apache o Litespeed como su servidor HTTP. Al igual que los ejemplos anteriores, .htaccess debe tener una línea sin comentarios como esta para establecer un límite máximo de PHP de 256 MB:
php_value memory_limit 256M
Los errores en la sintaxis de la aplicación y la configuración del servidor en wp-config.php , php.ini y .htaccess también pueden causar un WSOD. Es posible que deba corregirlos manualmente o reemplazarlos con sus valores predeterminados originales si están rompiendo su sitio. Si está utilizando un servidor web Apache o Litespeed, muchos complementos de WordPress pueden cambiar el archivo .htaccess que rige cómo funcionan. Los errores introducidos en cualquiera de estos archivos pueden generar un WSOD y derribar su sitio.
4. Su servidor HTTP está fallando
HTTP (o su forma cifrada y segura HTTPS) es el protocolo de transferencia de hipertexto que convierte a un servidor web en un servidor web. Es cómo los servidores sirven páginas web (documentos HTTP) a clientes (como navegadores) a pedido.
Los servidores HTTP comúnmente utilizados para los sitios de WordPress son Apache, Litespeed y NGINX. Sus pantallas de error se ven ligeramente diferentes y pueden variar en la forma en que los navegadores las muestran, pero todas reportan los mismos códigos de error HTTP.
Un error HTTP 500, también conocido como Error interno del servidor, indica que hay un problema inesperado con su servidor HTTP que le impide cumplir con las solicitudes HTTP. Otros códigos de error del servidor 5xx, especialmente 502 (Puerta de enlace incorrecta), 503 (Servicio no disponible) y 504 (Tiempo de espera de la puerta de enlace), indican que su servidor está sobrecargado o es inaccesible. El error interno 500 es un cajón de sastre para fallas en el servidor que impiden que devuelva la página/documento solicitado.
Su navegador puede proporcionar su propia versión única de las pantallas de error HTTP y puede mostrar sus propios códigos de error especiales. Google Chrome (y otros navegadores basados en Chromium) enumera y explica todos sus propios códigos de error internamente si navega a chrome://network-errors/ en su barra de direcciones mientras usa Chrome.
Problemas del lado del servidor
El software de servidor HTTP comúnmente utilizado para sitios de WordPress incluye Apache, Litespeed y NGINX. Muchos hosts de WordPress los usan con almacenamiento en caché para maximizar el rendimiento.
Si una actualización completa de su navegador o borrar las cookies y el caché de su navegador no elimina la pantalla de error 500, podría estar detectando algunos archivos de caché del lado del servidor defectuosos. El almacenamiento en caché del lado del servidor puede causar mucha confusión cuando no funciona bien, por lo que también debe intentar borrarlo. Su panel de control de alojamiento o la interfaz de administración de WordPress pueden tener controles de limpieza de caché.
Las causas comunes de un error HTTP 500 pueden incluir las siguientes condiciones del lado del servidor:
- Se ha excedido el límite de memoria de PHP.
- Otros errores de PHP cuando PHP no está configurado para mostrar errores.
- Permiso insuficiente para acceder a los archivos y carpetas del servidor.
- Errores de sintaxis en el archivo de configuración .htaccess.
Ya hemos abordado los límites de memoria de PHP y cómo aumentarlos. Profundizaremos en la depuración de PHP en la siguiente sección a continuación.
Los permisos incorrectos no deberían ocurrir en el alojamiento moderno y administrado de WordPress, pero son comunes en el alojamiento compartido tradicional. Los archivos deben configurarse en 664 o 644, las carpetas deben configurarse en 775 o 755 y wp-config.php debe configurarse en 660, 600 o 644. Obtenga más información sobre cómo cambiar los permisos de archivo en WordPress.org.
Si ha realizado cambios en su archivo .htaccess o está utilizando un complemento (a menudo o almacenamiento en caché) que lo cambia, es posible que deba revisarlo en busca de errores, restaurarlo o volver a crear un nuevo archivo .htaccess que funcione. Obtenga más información sobre .htaccess en WordPress.org.
Problemas del lado del cliente
Los errores HTTP 500 también pueden ser causados en el lado del cliente (en su navegador) por otras condiciones:
- Configuración incorrecta del navegador.
- Un caché corrupto.
- Archivos JavaScript corruptos que se ejecutan en su navegador.
- Problemas de conectividad a Internet.
Intente cargar su sitio en un navegador diferente para eliminar su navegador actual como el problema. Si tiene un problema con el navegador, intente restablecerlo a su configuración predeterminada. Deshabilite las extensiones o complementos del navegador que haya instalado para ver si están interactuando mal con su sitio.
Si su problema está relacionado con archivos de caché defectuosos, es posible que aún pueda acceder al área de administración de WordPress sin caché. Si aún puede iniciar sesión en la interfaz de administración de WordPress, es posible que pueda usar los interruptores de borrado de caché allí o probar los pasos adicionales de solución de problemas que se describen a continuación.
También es posible que un error HTTP 500 se deba a un problema con la base de datos, un problema con un complemento o tema en un sitio de WordPress, o un problema con WordPress mismo.
Para solucionar un error HTTP 500, debe activar el registro de errores para su servidor HTTP y PHP. A continuación, compruebe qué errores aparecen en ambos. También puede verificar y potencialmente aumentar el límite de memoria de PHP, desactivar complementos y cambiar a un tema predeterminado para ver si alguna de estas acciones recupera su sitio.
Veremos estos pasos con más detalle a continuación. Si seguirlos no elimina el error 500, comuníquese con el equipo de soporte de su servidor web para obtener más ayuda.
Cuando WordPress está realmente muerto
Si obtiene una pantalla completamente blanca en cada página frontal y trasera de su sitio de WordPress sin comentarios de error visibles, esa es la experiencia completa de WSOD. Puede obtener algunos mensajes de error e información de diagnóstico si sabe cómo acceder a los registros de errores de PHP y los registros del servidor HTTP. Activar la depuración de PHP para WordPress es otra opción. Su host puede tener algunas herramientas para que la depuración sea más accesible para usted. Pero si ese no es el caso, simplemente puede revisar esta lista de curas para el WSOD común hasta que encuentre su solución.
Una lista de verificación maestra para solucionar problemas y corregir la pantalla blanca de la muerte de WordPress
Para arreglar la pantalla blanca de la muerte de WordPress, seguir los siguientes pasos lo llevará a una solución. Están organizados en el orden de las causas más comunes de WSOD según las he experimentado, pero puede probarlos en cualquier orden.
Tiene más sentido priorizar las soluciones que parecen ser más relevantes para su situación particular.
El paso de registro y depuración de errores (#2) es el más técnico, pero es minucioso y siempre le dirá qué está causando que WordPress termine.
He proporcionado enlaces a algunos complementos gratuitos que pueden ser útiles herramientas de diagnóstico y reparación. También puede encontrar iThemes Security especialmente útil por su función de escaneo y reparación de bases de datos, así como por su detección de cambios de archivos. Incluso tiene herramientas de servidor para una mirada más profunda a la configuración y capacidades de su servidor.
En última instancia, una buena copia de seguridad reciente hará que su sitio vuelva a estar en línea en su último buen estado conocido. Backup Buddy es el mejor complemento para este rol.
Borre la memoria caché y las cookies de su navegador
Las páginas almacenadas en caché de su sitio en su navegador y en su servidor pueden mostrarle algo diferente de lo que realmente está sucediendo. Asegurémonos de que está viendo lo que WordPress está mostrando a los nuevos visitantes de su sitio.
Primero, borre el caché y las cookies de su navegador. Esto finalizará su sesión de usuario si ha iniciado sesión en WordPress o en cualquier otro sitio, por lo que lo verá como cualquier otro visitante.
Luego, use su panel de alojamiento y el administrador de WordPress (si está disponible) para borrar cualquier almacenamiento en caché del lado del servidor que su host y los complementos de caché de WordPress estén creando. Intente desactivar todo el almacenamiento en caché de su sitio y servidor. Realice una actualización completa en su navegador. Si eso soluciona el problema, es posible que el problema se deba a que tiene configuraciones de caché activadas que no funcionan en su sistema. A través de un proceso de eliminación, puede identificar cuáles funcionan y cuáles no.
2. Busque errores de PHP
El código PHP en el núcleo, los temas o los complementos de WordPress pueden generar un error fatal que hará que WordPress abandone el fantasma con una pantalla blanca de la muerte.
Para obtener más información sobre errores fatales de PHP y qué los está causando, puede activar el informe de errores de PHP y enviarlo a la pantalla, a un archivo de registro o a ambos. Es probable que los errores fatales apunten a la fuente del WSOD.
Como aplicación web basada en PHP, WordPress tiene su propio sistema de informes de diagnóstico para la depuración que lo ayuda a aprovechar las funciones de registro de errores de PHP. Para encenderlo y controlarlo, asegúrese de que haya una línea en wp-config.php que diga:
define('WP_DEBUG', verdadero);Es posible que deba agregarlo o cambiar el valor de falso a verdadero. Esto le dice a WordPress que active la depuración de PHP.
También puede tomar un atajo instalando y activando el complemento de depuración de WP. Activará la depuración de PHP para WordPress sin que tengas que modificar wp-config.php directamente tú mismo.
Los parámetros adicionales wp-config.php que se muestran a continuación imprimirán la salida de depuración en la pantalla como HTML y un archivo llamado "error_log" de forma predeterminada:
define('WP_DEBUG_DISPLAY', verdadero);
define('WP_DEBUG_LOG', verdadero);También puede ser útil obligar a WordPress a usar las versiones no optimizadas de sus dependencias de CSS y JavaScript en caso de que estén causando un problema:
define('SCRIPT_DEBUG', verdadero);El plugin Debug Bar es una útil herramienta adicional y complementaria. Le mostrará los datos de depuración en una interfaz agradable.
Para que esto suceda, en php.ini debe haber una línea que le dé a la constante error_reporting un valor diferente a NONE , como error_reporting = E_ALL . No debe haber un punto y coma encabezando esta línea; eso lo convierte en un comentario en lugar de una configuración activa. Tenga en cuenta que recibirá todos los errores, advertencias y avisos de PHP si usa E_ALL . Use un valor diferente como E_ERROR para registrar solo errores fatales de tiempo de ejecución que hacen que WordPress se bloquee.
3. Verifique los conflictos de temas y complementos
La depuración de errores de PHP como se describe en el paso anterior debería indicarle un tema claro o un archivo de complemento como fuente de su WSOD. También puede acercarse a él con un enfoque de proceso de eliminación menos técnico.
Solución de problemas de temas
La pantalla blanca de la muerte a menudo es causada por conflictos entre temas y/o complementos de WordPress. Para identificar la(s) fuente(s) de conflicto, puede intentar desactivar todos sus complementos y cambiar a los paquetes de temas predeterminados actuales y sin modificar con el núcleo de WordPress, como Twenty Twenty-Three.
Comience con el tema: es el más simple de probar. Si al cambiar su tema activo a un tema predeterminado no modificado y en buen estado, su sitio vuelve a estar en línea, sabe que su problema está en el tema que ha estado usando.
Echa un vistazo al archivo functions.php de tu tema si lo tiene. Si lo cambió recientemente, esa es una fuente probable de su problema. El archivo functions.php es donde se agrega el código funcional personalizado para usar con un tema cuando está activado. El código incorrecto y los errores de sintaxis aquí le darán un WSOD.
Solución de problemas de complementos
Puede desactivar complementos sin acceso al administrador de WordPress a través de la línea de comando/SSH o SFTP simplemente moviendo las carpetas de complementos fuera de la carpeta /wp-content/plugins/ temporalmente. Mi práctica es crear una subcarpeta de complementos llamada "A" para que aparezca primero en el directorio /plugins ordenado alfabéticamente. Luego muevo todas las demás carpetas de complementos a "A".
Una vez que haya hecho esto, vuelva a cargar su sitio. WordPress se comportará como si todos los complementos hubieran desaparecido. Todavía están instalados pero desactivados. Si la pantalla blanca de la muerte desaparece, puede intentar reactivar sus complementos y el tema uno por uno, actualizando su página de inicio cada vez para ver cuál hace que su sitio se bloquee.
Meks Quick Plugin Disabler es una herramienta útil que desactiva rápidamente todos los complementos activos y luego los vuelve a habilitar desde el administrador de WordPress a su disposición.
4. Reparación de archivos principales corruptos
Su WSOD puede ser la consecuencia de archivos corruptos del núcleo de WordPress. Si bien esto es poco probable, es simple reinstalar rápidamente la última versión de WordPress con un clic en el área de Actualizaciones del Panel de WordPress. Esto no dañará ninguno de sus complementos, temas o contenido existente, por lo que es una manera buena y fácil de confirmar que sus archivos principales están bien.
Si ninguno de los pasos anteriores ayuda, el WSOD puede deberse a un problema con el entorno de su servidor que está fuera de su alcance. En este caso, es posible que deba ponerse en contacto con su proveedor de alojamiento para obtener ayuda. Como último recurso, también puede hacer que su sitio vuelva al estado de "último estado bueno conocido" restaurando una copia de seguridad.
Cómo prevenir un WSOD: consejos para propietarios y creadores de sitios de WordPress
WordPress funcionaba bien, ¡y de repente apareció la pantalla blanca de la muerte!
Esto probablemente se deba a que USTED cambió algo crítico para el funcionamiento de WordPress.
Si está utilizando una cuenta de alojamiento de WordPress administrada sólida con Liquid Web o Nexcess que está configurada correctamente con suficientes recursos para las cosas que está haciendo con ella, se puede evitar el 99% de las formas en que puede romper WordPress con un WSOD.
¡El problema es que los propietarios de sitios no evitan estas prácticas!
Qué no hacer
- Codificación de vaqueros. Agregar o editar código funcional en un sitio en vivo a través de SFTP, la línea de comando o editores de código e insertadores de scripts dentro del administrador de WordPress. Un pequeño error hará que el sitio se caiga. Cambiar los archivos de configuración como
.htaccessywp-config.phptambién puede provocar la caída de un sitio. Trabaje en una prueba local o en un sitio de prueba en vivo (pero no público) en su lugar. - Instalación de temas dudosos, complementos y extensiones. Instalar software de baja calidad o incluso anulado en un sitio en vivo es una invitación a tener problemas. Simplemente agregar demasiadas cosas a la vez puede hacer que sea difícil determinar qué es finalmente un cambio importante. Similar a la codificación de vaqueros, instalar nuevos productos de código en un sitio en vivo es arriesgado. Pruebe bien en un local privado o en un sitio de ensayo primero.
- Almacenamiento en caché complicado. Hay varios tipos de almacenamiento en caché del lado del servidor que su host puede ofrecer que pueden no funcionar bien con todos los complementos de optimización de rendimiento y almacenamiento en caché. Cuando esté implementando nuevos métodos o configuraciones de almacenamiento en caché, pruebe cuidadosamente en entornos locales y de ensayo antes de implementar cambios en un sitio en vivo.
- Actualizando todo a la vez. Puede actualizar por lotes muchos temas y complementos a la vez. Normalmente esto funciona, pero si su servidor se agota, es posible que se quede atascado en el modo de mantenimiento. Además, el código recién actualizado puede presentar nuevos errores, conflictos o problemas de compatibilidad. Si esto sucede y su sitio deja de funcionar, será más difícil identificar el origen del problema. Podría ser cualquier cantidad de elementos si actualizó varios temas, complementos y extensiones a la vez. El código actualizado se puede probar localmente y en sitios de prueba en vivo antes de implementarlo en su sitio público principal.
Consejos para una vida sin WSOD
El WSOD puede ocurrirle a cualquier sitio de WordPress, pero no debería ser motivo de alarma. Seguir los consejos de esta guía puede ayudarlo a identificar el problema y solucionarlo rápidamente antes de que los visitantes de su sitio lo noten.
Los problemas con un sitio de WordPress subrayan la importancia del mantenimiento y cuidado adecuados. Mejor que reaccionar a los WSOD, puede aprender a trabajar en WordPress de una manera que nunca exponga a sus visitantes a mensajes de error y pantallas en blanco.
Realice sus cambios cuidadosa y deliberadamente. Trate con sus WSOD potenciales en un entorno de prueba o ensayo local. Estas son herramientas y características estándar para la mayoría de los hosts de WordPress administrados en la actualidad. Si sigue estas mejores prácticas básicas, no tendrá que preocuparse por la pantalla blanca de la muerte de WordPress.
El mejor complemento de seguridad de WordPress para asegurar y proteger WordPress
Actualmente, WordPress funciona en más del 40% de todos los sitios web, por lo que se ha convertido en un objetivo fácil para los piratas informáticos con intenciones maliciosas. El complemento iThemes Security Pro elimina las conjeturas de la seguridad de WordPress para que sea más fácil asegurar y proteger su sitio web de WordPress. Es como tener un experto en seguridad a tiempo completo en el personal que supervisa y protege constantemente su sitio de WordPress por usted.
Dan Knauss es el generalista de contenido técnico de StellarWP. Ha sido escritor, profesor y autónomo trabajando en código abierto desde finales de la década de 1990 y con WordPress desde 2004.