web-dev-qa-db-fra.com

Page d'erreur 500 personnalisée: existe-t-il un moyen de thème une erreur fatale?

Dans /core/includes/errors.inc, en cas d'erreur fatale, il génère une réponse avec le message "Le site Web a rencontré une erreur inattendue. Veuillez réessayer plus tard." et une trace arrière, si error_level est défini sur verbeux, et sans la trace arrière sinon.

Il semble qu'à ce stade, il n'y a aucun moyen, avec un abonné à l'événement, de capturer la réponse et de la modifier.

Est-ce exact?

Ou existe-t-il un moyen d'envelopper la sortie de la ligne 268 d'erreurs.inc dans Drupal 8.4 avec balisage?

Remarque, il y a un autre réponse qui fonctionne si ce n'est pas une erreur fatale , mais qui n'offre pas une solution complète.

En outre, j'ai examiné la directive .htaccess et Apache ErrorDocument, mais cela était erroné . Une fois Apache passé à PHP, il ne peut plus utiliser cette directive. C'est pour de vraies erreurs de serveur .

8event-subscriber
6
oknate

Le HttpKernel de Symfony utilise le répartiteur d'événements pour permettre aux abonnés de gérer les exceptions et d'envoyer des réponses personnalisées. Ce n'est que si aucun abonné ne le fait qu'il lèvera l'exception plus haut et le laissera atteindre le gestionnaire d'erreurs global. (À ce moment-là, il est en effet trop tard pour faire autre chose.)

Drupal est déjà livré avec un tel abonné (ou plutôt plusieurs d'entre eux, qui vérifient des conditions particulières) pour les exceptions HTTP (ce sont des implémenteurs de \Symfony\Component\HttpKernel\Exception\HttpExceptionInterface, Tels que NotFoundHttpException.)

Si vous devez absolument intercepter les exceptions non-HTTP où qu'elles se produisent et renvoyer des réponses personnalisées, vous pouvez créer votre propre abonné (voir Drupal\Core\EventSubscriber\HttpExceptionSubscriberBase) Et lui donner une très faible priorité ( <-128) pour éviter d'interférer avec les principaux abonnés aux exceptions HTTP.

Cependant, en termes d'architecture, je dirais que ce n'est pas une bonne façon de procéder. Si vous avez un contrôleur qui déclenche une exception particulière, il doit l'attraper et lever l'exception HTTP appropriée à la place. Cela nécessite également beaucoup, beaucoup moins de code que de jouer avec les abonnés aux événements. ;)

Si besoin est, vous pouvez même lever une exception ServiceUnavailableHttpException (503) ou définir un état personnalisé comme new HttpException(500) s'il n'y a pas de classe pour cela.

Les abonnés d'exception de Drupal core ne gèrent pas réellement les erreurs 5xx, mais vous pouvez créer le vôtre, ce qui ressemblerait probablement à ceci:

class Custom5xxHtmlSubscriber extends HttpExceptionSubscriberBase {
  public function on5xx(GetResponseForExceptionEvent $event) {
     // Do stuff
     (new Response())->send();
  }

Avec une définition de service correspondante comme celle-ci:

  custom5xxsubscriber:
    class: ...
    tags:
      - { name: event_subscriber }
3
Christoph Burschka