Página de error amigable para reemplazar WSOD

Esto debería ser lo más fácil de hacer, pero por alguna razón simplemente no puedo hacerlo.

Estoy tratando de obtener una página amigable de error estático para reemplazar los desagradables 500 escenarios. Por ahora solo estoy tratando de replicar una situación 500 en mi máquina local (Drupal 7 ejecutándose en MAMP) agregando algunos caracteres basura en la parte superior de mi template.php en mi tema, lo que desencadena una situación 500, pero para alguna razón la directiva ErrorDocument en mi .htaccessarchivo de configuración o Apache no tiene ningún efecto.

Lo que estoy haciendo es simplemente esto:

ErrorDocument 500 /500.html

Y tengo la página html estática más simple en la raíz de mi sitio con el nombre de 500.html.

Aún así, cuando intencionalmente rompo template.php, obtengo la temida White Screen Of Death en lugar de mi amigable página de error amigable.

¿Qué estoy haciendo mal aquí? Lo he hecho mil millones de veces en configuraciones que no son de Drupal, pero no puedo entenderlo.

ACTUALIZACIÓN : Parece que esta pregunta es bastante redundante en mi caso de uso específico en este momento, ya que la nube de desarrollo de Acquia que utilizamos para ejecutar la aplicación en cuestión ni siquiera admite la personalización de páginas de error de la serie 500 en este momento. Esperamos que implementen soporte para eso pronto.

500 páginas de error son estrictamente páginas de error del servidor. Una vez que el servidor entrega la ejecución a PHP, Drupal / PHP es responsable de servir su propia página de error. Puede intentar decirle a Drupal que redirija al usuario a una página de error personalizada, junto con un encabezado de estado HTTP 500, cuando recibe ciertos errores dentro de un try...catchbloque.

Sin embargo, tenga en cuenta que algunos WSOD pueden ocurrir a nivel del sistema y podrían causar un error fatal que detenga inmediatamente la ejecución y posiblemente impida la catchejecución . Un ejemplo de esto es cuando su base de datos no está ajustada correctamente para manejar consultas de cierto tamaño (como cuando se realizan operaciones de revertir todas las operaciones): la base de datos puede bloquearse, lo que le proporciona un insta-WSOD.

Diría que lo mejor que puede hacer es verificar sus registros de errores de apache, MySQL y PHP, y tratar de aislar la causa raíz de WSOD caso por caso, en lugar de tratar de ocultarlos con página de error Si bien los errores que causan las típicas páginas de error de 500 servidores a veces son inevitables, y tener páginas de error de servidor personalizadas en producción es factible, tener WSODs en vivo no lo es.

Parece que tiene las páginas de error del servidor configuradas correctamente. ¡Solo necesita hacer la distinción de que las páginas de error típicas del servidor! = WSOD. Las páginas de error del servidor pueden activarse debido al alto tráfico y los cuellos de botella de recursos, pero en realidad no debería haber que ocurran WSOD en la producción, punto. Esto suele suceder debido a una codificación, optimización o configuración deficientes. Si aún ve un WSOD, asegúrese de encontrar primero (y resolver) la causa raíz del problema, en lugar de intentar aplicarle una curita.

Está obteniendo WSOD porque desactivó el informe de errores en php.ini. Este es un problema de seguridad: si tiene un error y el pirata informático ve de qué se trata, puede utilizarlo para piratear el sitio.

Sin embargo, si desea interceptar el error, debe habilitar la visualización de los errores en php.ini (el ejemplo solo mostrará errores graves):

error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT

Y luego, puede configurar los documentos de error en el archivo htaccess:

ErrorDocument 401 http://yourwebsite.com/error-401
ErrorDocument 403 http://yourwebsite.com/error-403
ErrorDocument 500 http://yourwebsite.com/error-500

Alternativamente, puede especificar los errores en el archivo settings.php de Drupal .

En NGINX:

error_page 403 = /error.php?code=403;   
error_page 404 = /error.php?code=404;
error_page 500 = /error.php?code=500;

Como está ejecutando Apache en MAMP, configúrelo en .htaccess. Recuerde que AllowOverrideen la configuración de apache debe estar activado (generalmente lo está).

¿Has activado el informe de errores? (admin / config / development / logging -> Establecer todos los mensajes para mostrar mensajes de error )

Por defecto, Drupal muestra un WSOD como una característica de seguridad.

Supongo que la respuesta es "leer los documentos", ver https://www.drupal.org/node/195435

Entonces, básicamente, puede crear los archivos de plantilla nombrados maintenance-page.tpl.phpy maintenance-page--offline.tpl.phpcodificar algunas configuraciones settings.php.

EDITAR:

No parece importar qué nivel error_reportingestá ajustado en o si se ha establecido display_errorsa ono off. Cuando tenga un maintenance-page--offline.tpl.phparchivo en su lugar, Drupal mostrará esta página cuando la base de datos desaparezca. Tampoco importa lo que haya configurado /admin/config/development/loggingen el lado del administrador. Si solo tiene errores de sintaxis, que era la situación del OP, que en realidad no desencadenará un 500, es un 200 con un error de PHP que se muestra u oculta según el php.ini display_errorconjunto. No sé de ninguna otra manera que no sea agregar su lógica personalizada de manejo de errores a través de su código personalizado según sea necesario.

Reemplazar todos los WSOD por algo más requeriría piratear el núcleo: no desea hacer esto. Drupal define sus propios manejadores de errores en bootstrap.inc y errors.inc. Si tuviera que perder el tiempo con ese código, tendría que asegurarse de tener en cuenta todas las cosas que podrían estar mal cuando la ejecución llegara a esta etapa (sin base de datos, sin motor de temas, sin tema, sin configuración, etc.).

Hice un proyecto de sandbox para hacer esto.

Pude lograr esto extendiendo HttpExceptionSubscriberBase en /src/EventSubscriber/fivehundredEventSubscriber.php

    <?php
namespace Drupal\five_hundred\EventSubscriber;

use Drupal\Core\EventSubscriber\HttpExceptionSubscriberBase;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpKernel\Event\GetResponseForExceptionEvent;
use Symfony\Component\Serializer\SerializerInterface;

class five_hundredEventSubscriber extends HttpExceptionSubscriberBase {

      public function __construct($stack) {

        if(
          (
            null !== $stack->getCurrentRequest()->attributes->get('exception')->getCode()
            && $stack->getCurrentRequest()->attributes->get('exception')->getCode() == 500
          )||(
            null !== $stack->getCurrentRequest()->attributes->get('exception')->getStatusCode()
            && $stack->getCurrentRequest()->attributes->get('exception')->getStatusCode() == 500
          )
        ){
            $response = new Response();
            $errorDocumentHtml = 'html here';
            $response->setContent($errorDocumentHtml);
            $response->setStatusCode(500, '500 Internal Server Error');
            $response->send();
            die();
        }
      }

      /**
       * {@inheritdoc}
       */
      protected function getHandledFormats() {
        return array('html','');
      }


    }
?>

Y deberá agregar el servicio en su module.services.yml

services:
  five_hundred.:
    class: Drupal\five_hundred\EventSubscriber\five_hundredEventSubscriber
    arguments: ['@request_stack']
    tags:
      - { name: event_subscriber }