Recuperación de caída

Mi sitio WordPress está caído

"There has been a critical error on this website." El sitio público está caído, wp-admin caído con él, y el único email que podría dejarte volver a entrar quizá nunca llegue. Esto es lo que se rompió de verdad - y el camino más rápido de vuelta a un sitio que funciona.

Lo que "There has been a critical error" significa de verdad

En algún lugar de tu stack - casi siempre un plugin o el tema - una línea de PHP falló con tanta gravedad que WordPress no pudo seguir. El handler de errores fatales la capturó e imprimió este mensaje en lugar de una página en blanco. Eso es todo el error. Tus archivos siguen en el disco, tu base de datos sigue ahí, tu contenido está bien. Una extensión se estrelló y se llevó el sitio entero con ella.

El patrón

Un plugin se actualiza. O tu hosting sube la versión de PHP. O alguien edita un archivo por el editor de temas. La siguiente petición responde con "There has been a critical error on this website." El frontend está caído. wp-login.php también está caído, así que no puedes desactivar el plugin sospechoso - y el email que podría devolverte el acceso va a la dirección que esté en Ajustes → Generales.

La forma antigua del mismo crash es la White Screen of Death: el fatal dispara antes de que WordPress pueda renderizar nada, así que el navegador recibe una página vacía. Misma causa, menos información. Ambas vienen del mismo sitio, y ambas están cubiertas abajo.

Lo que WordPress hace después - y dónde se atasca

Desde WordPress 5.2, el core tiene una respuesta real. Cuando el fatal dispara, el handler de errores fatales lo detecta y envía un enlace de Recovery Mode a la dirección admin del sitio. Haz clic en el enlace, vuelve a entrar, y Recovery Mode pausa la extensión rota - el sitio vuelve con el plugin desactivado y un aviso que lo nombra. El mecanismo es sólido. La entrega es la parte débil.

Dónde se atasca el flujo por defecto
  • El enlace va al email que esté en Ajustes → Generales - a menudo un buzón que nadie lee
  • wp_mail() puede ser lento, caer en el filtro de spam o tenerlo el hosting desactivado del todo
  • El sitio sigue caído mientras esperas un mensaje que quizá nunca llegue
  • Cada minuto de espera es otro minuto de página de error para tus visitantes
Con los drop-ins activos
  • Un administrador conectado va directo a la URL firmada de Recovery Mode - sin ida y vuelta de email
  • Sigues demostrando que eres tú: la puerta de re-login del core se queda en su sitio
  • El plugin roto queda pausado por el propio handler del core en la siguiente petición
  • Una pantalla en blanco se convierte en una página de error real en lugar de una respuesta vacía

El mismo destino de las dos formas. El drop-in solo quita el paso más lento y menos fiable de en medio.

Qué hacen los drop-ins de fatal error recovery

Dos drop-ins se despliegan en wp-content cuando WP Multitool se activa y se quedan ahí hasta que desactivas el plugin. No hay interruptor ni nada que configurar - un sitio no puede perder su recuperación de caída porque alguien apagó un ajuste.

Archivo Qué hace
fatal-error-handler.php Sobrescribe el handler de errores fatales del core. Cuando un administrador conectado topa con un fatal de plugin o tema, construye la URL firmada de Recovery Mode del core al momento y te manda a la puerta de login - saltándose el email por completo
php-error.php Renderiza el propio error. Un fatal que antes terminaba en un body en blanco ahora produce la página real de "critical error" de WordPress, para que siempre recibas una respuesta visible

Después de volver a escribir tu contraseña, el próximo crash pasa por el propio handler del core, que pausa la extensión ofensora. Esa pausa es lo que devuelve el sitio - mi drop-in quita la espera entre el crash y el enlace de recuperación. La URL es la firmada del core; nada de ella se filtra a tus visitantes.

Lo que no hará - lee esto antes de fiarte de él

  • Los visitantes desconectados ven la misma página de error de todas formas. El sitio está caído para ellos hasta que la extensión rota queda pausada. Dar a extraños un enlace de recuperación sería darles tu panel de admin, así que solo un admin conectado recibe uno.
  • Solo fatales de plugins y temas. Un crash dentro del core de WordPress, un drop-in o un wp-config.php roto no puede ser pausado por Recovery Mode, así que recibes la página de error simple.
  • Sin multisite. En una instalación de red el drop-in se aparta y el core maneja el crash de la forma por defecto.
  • No es un backup. Pausar un plugin roto no restaura nada - si el crash corrompió datos, necesitas el backup de tu hosting o uno de verdad.
  • No previene el crash. El código malo sigue corriendo y sigue fallando. Vuelves a entrar más rápido, con el culpable ya nombrado.
  • Una base de datos muerta o una caída del hosting está por debajo de esta capa. WordPress muere antes de que el handler cargue, así que no hay nada que interceptar.
¿Rompiste el propio wp-config.php?

Credenciales de base de datos equivocadas o una mala edición matan WordPress antes de que cargue cualquier handler. Para ese caso Config Manager (Pro) incluye un comando de rescate WP-CLI que restaura un backup de wp-config sin arrancar WordPress en absoluto - funciona con la base de datos completamente inalcanzable.

¿Ya dentro? Ahora mira qué se rompió de verdad

Recovery Mode nombra la extensión que pausó. El error que mató el sitio está en debug.log - si tienes WP_DEBUG_LOG encendido - y un sitio concurrido puede escribir cientos de líneas casi idénticas por petición, así que la línea fatal queda bajo una pila de repeticiones.

Debug Log Guard (Pro) lee el log sin cargarlo. Agrupa las repeticiones en una tabla - mensaje, contador, plugin o tema de origen, primera y última vez que se vio - y transmite el tail, así que un log de varios gigabytes abre en segundos en lugar de estrellar tu editor. La línea que tumbó el sitio flota a la cima, ya atribuida a su fuente.

¿Dentro y quieres la prueba de qué se rompió? Debug Log Guard convierte el log en una tabla agrupada con el culpable nombrado.

Pro desde $79/año →

FAQ: sitio WordPress caído

¿Por qué mi sitio WordPress dice "There has been a critical error on this website"?

Un fatal de PHP - casi siempre dentro de un plugin o el theme - detuvo la petición. WordPress lo capturó en un shutdown handler e imprimió este mensaje en lugar de una página en blanco. Tus archivos y tu base de datos están intactos; una extensión se estrelló y se llevó el sitio con ella.

¿Cómo vuelvo a entrar en wp-admin con el sitio caído?

WordPress envía un enlace de Recovery Mode a la dirección admin del sitio - haz clic, vuelve a entrar, y el plugin roto queda pausado. Con los drop-ins de WP Multitool, un administrador conectado es enviado directo a esa URL firmada de Recovery Mode cuando el fatal ocurre, así que no hay email que esperar.

El email de recovery mode de WordPress nunca llegó - ¿y ahora qué?

Revisa spam, luego revisa qué dirección está en Ajustes → Generales - a menudo es un buzón que nadie lee, y algunos hostings ralentizan o bloquean wp_mail() directamente. El drop-in de fatal error recovery construye la URL firmada al momento para un admin conectado en lugar de enviarla, así que el flujo no puede atascarse en email.

¿Mi sitio se fue para siempre? ¿Me hackearon?

Casi nunca. Un error crítico después de una actualización, una subida de versión de PHP o una edición de archivo es una extensión mala, no un hack ni datos perdidos. Recovery Mode pausa al ofensor y el sitio vuelve; tu contenido, archivos y base de datos quedan intactos.

¿El drop-in de recuperación arregla el error?

No - te mete en Recovery Mode más rápido y la extensión rota queda pausada por el propio handler del core. El plugin que se estrelló aún necesita actualización, reemplazo o un reporte de bug a su autor. El drop-in te da el acceso y un nombre, no un parche.

¿Funciona fatal error recovery en multisite?

No. En una instalación de red el drop-in se aparta y WordPress maneja el crash de la forma por defecto - el email de recuperación a la dirección admin. Las instalaciones de un solo sitio reciben la redirección directa.

¿Y una pantalla en blanco sin ningún mensaje de error?

Eso es la White Screen of Death - un fatal que dispara antes de que WordPress pueda renderizar su página de error. El drop-in php-error.php de WP Multitool se asegura de que el crash siga produciendo la página real de "critical error", para que siempre veas algo en lugar de una respuesta vacía.

Vuelve a entrar en lugar de esperar un email

Los drop-ins se despliegan cuando WP Multitool se activa - sin setup, sin interruptor que olvidar. Debug Log Guard y el comando de rescate de Config Manager vienen con Pro desde $79/año por un sitio, y cada plan de pago incluye los 19 módulos.

Consigue Pro - desde $79 al año Guía de debug.log Todos los planes en la página de precios →