Nous pouvons modifier la sortie booléenne de la wp_is_fatal_error_handler_enabled()fonction de deux manières:
Constant
Définissez la WP_DISABLE_FATAL_ERROR_HANDLERconstante truedans le wp-config.phpfichier:
/**
* Disable the fatal error handler.
*/
const WP_DISABLE_FATAL_ERROR_HANDLER = true;
ou
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );
Filtre
Utilisez un wp_fatal_error_handler_enabledfiltre bool:
/**
* Disable the fatal error handler.
*/
add_filter( 'wp_fatal_error_handler_enabled', '__return_false' );
Remarques
Voir billet # 44458
Le wp_fatal_error_handler_enabledfiltre remplacera la valeur de la WP_DISABLE_FATAL_ERROR_HANDLERconstante.
Faites également attention à une éventuelle confusion booléenne avec la désactivation constante mais l' activation du filtre .
Dans mes tests, l'approche du filtre, en tant que plug - in indispensable , ne fonctionne pas comme prévu, j'utilise donc la constante à la place. J'espère que je pourrai approfondir cette question.
On peut également ajouter un fichier de dépôt personnalisé fatal-error-handler.phpdans le wp-contentrépertoire ( src ), pour remplacer la WP_Fatal_Error_Handlerclasse selon les besoins. Nous devons utiliser un nom de classe différent et il doit définir la handle()méthode comme la fonction d'arrêt enregistrée .
Un exemple simple pour le désactiver serait de remplacer la classe du gestionnaire d'erreurs par défaut par une classe personnalisée qui ne fait rien:
<?php
class WPSE_Fatal_Error_Handler {
public function handle() {}
}
return new WPSE_Fatal_Error_Handler;
La classe anonyme en PHP 7+ semble également fonctionner:
<?php
return new Class(){
public function handle() {}
};
Il pourrait également étendre la WP_Fatal_Error_Handlerclasse par défaut si nécessaire.
Ensuite, il y a la WP_SANDBOX_SCRAPINGconstante. Voir # 46045
La définition de la valeur WP_DEBUGtrue ne désactive pas la protection WSOD. C'est par conception. Voir # 46825