Bootstrap/Load: Introduce fatal error handler.
This changeset introduces a `WP_Fatal_Error_Handler` class that detects fatal errors and displays a more user-friendly message about the site experiencing technical difficulties.
Websites that have custom requirements in that regard can implement their own fatal error handler by adding a `fatal-error-handler.php` drop-in that returns the handler instance to use, which must be based on a class that inherits `WP_Fatal_Error_Handler`. That handler will then be used in place of the default one. Alternatively, the fatal error handler feature can be completely disable through a constant `WP_DISABLE_FATAL_ERROR_HANDLER`.
Websites that would like to modify specifically the error template displayed in the frontend can add a `php-error.php` drop-in that works similarly to the existing `db-error.php` drop-in. For more granular customization, the fatal error handler also includes new filters `wp_should_handle_php_error`, `wp_php_error_message` and `wp_php_error_args`.
Props afragen, bradleyt, flixos90, ocean90, schlessera, SergeyBiryukov, spacedmonkey, timothyblynjacobs.
See #46130, #44458.
Built from https://develop.svn.wordpress.org/trunk@44962
git-svn-id: http://core.svn.wordpress.org/trunk@44793 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-03-21 12:03:51 -04:00
< ? php
/**
* Error Protection API : WP_Fatal_Error_Handler class
*
* @ package WordPress
2020-01-28 19:45:18 -05:00
* @ since 5.2 . 0
Bootstrap/Load: Introduce fatal error handler.
This changeset introduces a `WP_Fatal_Error_Handler` class that detects fatal errors and displays a more user-friendly message about the site experiencing technical difficulties.
Websites that have custom requirements in that regard can implement their own fatal error handler by adding a `fatal-error-handler.php` drop-in that returns the handler instance to use, which must be based on a class that inherits `WP_Fatal_Error_Handler`. That handler will then be used in place of the default one. Alternatively, the fatal error handler feature can be completely disable through a constant `WP_DISABLE_FATAL_ERROR_HANDLER`.
Websites that would like to modify specifically the error template displayed in the frontend can add a `php-error.php` drop-in that works similarly to the existing `db-error.php` drop-in. For more granular customization, the fatal error handler also includes new filters `wp_should_handle_php_error`, `wp_php_error_message` and `wp_php_error_args`.
Props afragen, bradleyt, flixos90, ocean90, schlessera, SergeyBiryukov, spacedmonkey, timothyblynjacobs.
See #46130, #44458.
Built from https://develop.svn.wordpress.org/trunk@44962
git-svn-id: http://core.svn.wordpress.org/trunk@44793 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-03-21 12:03:51 -04:00
*/
/**
* Core class used as the default shutdown handler for fatal errors .
*
* A drop - in 'fatal-error-handler.php' can be used to override the instance of this class and use a custom
* implementation for the fatal error handler that WordPress registers . The custom class should extend this class and
* can override its methods individually as necessary . The file must return the instance of the class that should be
* registered .
*
* @ since 5.2 . 0
*/
class WP_Fatal_Error_Handler {
/**
* Runs the shutdown handler .
*
* This method is registered via `register_shutdown_function()` .
*
* @ since 5.2 . 0
*/
public function handle () {
Bootstrap/Load: Ensure `WP_Fatal_Error_Handler` does not conflict with existing mechanisms treating fatal errors.
Prior to this change, resuming or activating a plugin or theme that is still broken would result in a redirect loop if in recovery mode. If outside recovery mode, it would cause the error template to be displayed.
Furthermore this applies to breaking a plugin or theme when editing from the backend.
Props aandrewdixon, azaozz, dhanukanuwan, henrywright, ocean90, ohiosierra, PandelisZ, xkon.
Fixes #46045, #46751.
Built from https://develop.svn.wordpress.org/trunk@45114
git-svn-id: http://core.svn.wordpress.org/trunk@44923 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-04-05 11:20:55 -04:00
if ( defined ( 'WP_SANDBOX_SCRAPING' ) && WP_SANDBOX_SCRAPING ) {
return ;
}
2020-05-06 10:38:17 -04:00
// Do not trigger the fatal error handler while updates are being installed.
2020-05-31 15:54:24 -04:00
if ( wp_is_maintenance_mode () ) {
2020-05-06 10:38:17 -04:00
return ;
}
Bootstrap/Load: Introduce fatal error handler.
This changeset introduces a `WP_Fatal_Error_Handler` class that detects fatal errors and displays a more user-friendly message about the site experiencing technical difficulties.
Websites that have custom requirements in that regard can implement their own fatal error handler by adding a `fatal-error-handler.php` drop-in that returns the handler instance to use, which must be based on a class that inherits `WP_Fatal_Error_Handler`. That handler will then be used in place of the default one. Alternatively, the fatal error handler feature can be completely disable through a constant `WP_DISABLE_FATAL_ERROR_HANDLER`.
Websites that would like to modify specifically the error template displayed in the frontend can add a `php-error.php` drop-in that works similarly to the existing `db-error.php` drop-in. For more granular customization, the fatal error handler also includes new filters `wp_should_handle_php_error`, `wp_php_error_message` and `wp_php_error_args`.
Props afragen, bradleyt, flixos90, ocean90, schlessera, SergeyBiryukov, spacedmonkey, timothyblynjacobs.
See #46130, #44458.
Built from https://develop.svn.wordpress.org/trunk@44962
git-svn-id: http://core.svn.wordpress.org/trunk@44793 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-03-21 12:03:51 -04:00
try {
// Bail if no error found.
$error = $this -> detect_error ();
if ( ! $error ) {
return ;
}
2019-05-15 14:19:51 -04:00
if ( ! isset ( $GLOBALS [ 'wp_locale' ] ) && function_exists ( 'load_default_textdomain' ) ) {
2019-05-02 06:53:52 -04:00
load_default_textdomain ();
}
2019-09-14 21:18:55 -04:00
$handled = false ;
Bootstrap/Load: Introduce a recovery mode for fixing fatal errors.
Using the new fatal handler introduced in [44962], an email is sent to the admin when a fatal error occurs. This email includes a secret link to enter recovery mode. When clicked, the link will be validated and on success a cookie will be placed on the client, enabling recovery mode for that user. This functionality is executed early before plugins and themes are loaded, in order to be unaffected by potential fatal errors these might be causing.
When in recovery mode, broken plugins and themes will be paused for that client, so that they are able to access the admin backend despite of these errors. They are notified about the broken extensions and the errors caused, and can then decide whether they would like to temporarily deactivate the extension or fix the problem and resume the extension.
A link in the admin bar allows the client to exit recovery mode.
Props timothyblynjacobs, afragen, flixos90, nerrad, miss_jwo, schlessera, spacedmonkey, swissspidy.
Fixes #46130, #44458.
Built from https://develop.svn.wordpress.org/trunk@44973
git-svn-id: http://core.svn.wordpress.org/trunk@44804 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-03-21 17:53:51 -04:00
if ( ! is_multisite () && wp_recovery_mode () -> is_initialized () ) {
2019-09-14 21:18:55 -04:00
$handled = wp_recovery_mode () -> handle_error ( $error );
Bootstrap/Load: Introduce a recovery mode for fixing fatal errors.
Using the new fatal handler introduced in [44962], an email is sent to the admin when a fatal error occurs. This email includes a secret link to enter recovery mode. When clicked, the link will be validated and on success a cookie will be placed on the client, enabling recovery mode for that user. This functionality is executed early before plugins and themes are loaded, in order to be unaffected by potential fatal errors these might be causing.
When in recovery mode, broken plugins and themes will be paused for that client, so that they are able to access the admin backend despite of these errors. They are notified about the broken extensions and the errors caused, and can then decide whether they would like to temporarily deactivate the extension or fix the problem and resume the extension.
A link in the admin bar allows the client to exit recovery mode.
Props timothyblynjacobs, afragen, flixos90, nerrad, miss_jwo, schlessera, spacedmonkey, swissspidy.
Fixes #46130, #44458.
Built from https://develop.svn.wordpress.org/trunk@44973
git-svn-id: http://core.svn.wordpress.org/trunk@44804 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-03-21 17:53:51 -04:00
}
2019-03-26 16:30:53 -04:00
// Display the PHP error template if headers not sent.
2019-04-16 00:38:51 -04:00
if ( is_admin () || ! headers_sent () ) {
2019-09-14 21:18:55 -04:00
$this -> display_error_template ( $error , $handled );
2019-03-26 16:30:53 -04:00
}
Bootstrap/Load: Introduce fatal error handler.
This changeset introduces a `WP_Fatal_Error_Handler` class that detects fatal errors and displays a more user-friendly message about the site experiencing technical difficulties.
Websites that have custom requirements in that regard can implement their own fatal error handler by adding a `fatal-error-handler.php` drop-in that returns the handler instance to use, which must be based on a class that inherits `WP_Fatal_Error_Handler`. That handler will then be used in place of the default one. Alternatively, the fatal error handler feature can be completely disable through a constant `WP_DISABLE_FATAL_ERROR_HANDLER`.
Websites that would like to modify specifically the error template displayed in the frontend can add a `php-error.php` drop-in that works similarly to the existing `db-error.php` drop-in. For more granular customization, the fatal error handler also includes new filters `wp_should_handle_php_error`, `wp_php_error_message` and `wp_php_error_args`.
Props afragen, bradleyt, flixos90, ocean90, schlessera, SergeyBiryukov, spacedmonkey, timothyblynjacobs.
See #46130, #44458.
Built from https://develop.svn.wordpress.org/trunk@44962
git-svn-id: http://core.svn.wordpress.org/trunk@44793 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-03-21 12:03:51 -04:00
} catch ( Exception $e ) {
// Catch exceptions and remain silent.
}
}
/**
* Detects the error causing the crash if it should be handled .
*
* @ since 5.2 . 0
*
* @ return array | null Error that was triggered , or null if no error received or if the error should not be handled .
*/
protected function detect_error () {
$error = error_get_last ();
// No error, just skip the error handling code.
if ( null === $error ) {
return null ;
}
// Bail if this error should not be handled.
if ( ! $this -> should_handle_error ( $error ) ) {
return null ;
}
return $error ;
}
/**
* Determines whether we are dealing with an error that WordPress should handle
* in order to protect the admin backend against WSODs .
*
* @ since 5.2 . 0
*
* @ param array $error Error information retrieved from error_get_last () .
* @ return bool Whether WordPress should handle this error .
*/
protected function should_handle_error ( $error ) {
$error_types_to_handle = array (
E_ERROR ,
E_PARSE ,
E_USER_ERROR ,
E_COMPILE_ERROR ,
E_RECOVERABLE_ERROR ,
);
if ( isset ( $error [ 'type' ] ) && in_array ( $error [ 'type' ], $error_types_to_handle , true ) ) {
return true ;
}
/**
* Filters whether a given thrown error should be handled by the fatal error handler .
*
* This filter is only fired if the error is not already configured to be handled by WordPress core . As such ,
* it exclusively allows adding further rules for which errors should be handled , but not removing existing
* ones .
*
* @ since 5.2 . 0
*
* @ param bool $should_handle_error Whether the error should be handled by the fatal error handler .
* @ param array $error Error information retrieved from error_get_last () .
*/
return ( bool ) apply_filters ( 'wp_should_handle_php_error' , false , $error );
}
/**
* Displays the PHP error template and sends the HTTP status code , typically 500.
*
* A drop - in 'php-error.php' can be used as a custom template . This drop - in should control the HTTP status code and
* print the HTML markup indicating that a PHP error occurred . Note that this drop - in may potentially be executed
* very early in the WordPress bootstrap process , so any core functions used that are not part of
* `wp-includes/load.php` should be checked for before being called .
*
* If no such drop - in is available , this will call { @ see WP_Fatal_Error_Handler :: display_default_error_template ()} .
*
* @ since 5.2 . 0
2019-09-14 21:18:55 -04:00
* @ since 5.3 . 0 The `$handled` parameter was added .
2019-03-26 20:16:51 -04:00
*
2019-09-14 21:18:55 -04:00
* @ param array $error Error information retrieved from `error_get_last()` .
* @ param true | WP_Error $handled Whether Recovery Mode handled the fatal error .
Bootstrap/Load: Introduce fatal error handler.
This changeset introduces a `WP_Fatal_Error_Handler` class that detects fatal errors and displays a more user-friendly message about the site experiencing technical difficulties.
Websites that have custom requirements in that regard can implement their own fatal error handler by adding a `fatal-error-handler.php` drop-in that returns the handler instance to use, which must be based on a class that inherits `WP_Fatal_Error_Handler`. That handler will then be used in place of the default one. Alternatively, the fatal error handler feature can be completely disable through a constant `WP_DISABLE_FATAL_ERROR_HANDLER`.
Websites that would like to modify specifically the error template displayed in the frontend can add a `php-error.php` drop-in that works similarly to the existing `db-error.php` drop-in. For more granular customization, the fatal error handler also includes new filters `wp_should_handle_php_error`, `wp_php_error_message` and `wp_php_error_args`.
Props afragen, bradleyt, flixos90, ocean90, schlessera, SergeyBiryukov, spacedmonkey, timothyblynjacobs.
See #46130, #44458.
Built from https://develop.svn.wordpress.org/trunk@44962
git-svn-id: http://core.svn.wordpress.org/trunk@44793 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-03-21 12:03:51 -04:00
*/
2019-09-14 21:18:55 -04:00
protected function display_error_template ( $error , $handled ) {
Bootstrap/Load: Introduce fatal error handler.
This changeset introduces a `WP_Fatal_Error_Handler` class that detects fatal errors and displays a more user-friendly message about the site experiencing technical difficulties.
Websites that have custom requirements in that regard can implement their own fatal error handler by adding a `fatal-error-handler.php` drop-in that returns the handler instance to use, which must be based on a class that inherits `WP_Fatal_Error_Handler`. That handler will then be used in place of the default one. Alternatively, the fatal error handler feature can be completely disable through a constant `WP_DISABLE_FATAL_ERROR_HANDLER`.
Websites that would like to modify specifically the error template displayed in the frontend can add a `php-error.php` drop-in that works similarly to the existing `db-error.php` drop-in. For more granular customization, the fatal error handler also includes new filters `wp_should_handle_php_error`, `wp_php_error_message` and `wp_php_error_args`.
Props afragen, bradleyt, flixos90, ocean90, schlessera, SergeyBiryukov, spacedmonkey, timothyblynjacobs.
See #46130, #44458.
Built from https://develop.svn.wordpress.org/trunk@44962
git-svn-id: http://core.svn.wordpress.org/trunk@44793 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-03-21 12:03:51 -04:00
if ( defined ( 'WP_CONTENT_DIR' ) ) {
// Load custom PHP error template, if present.
$php_error_pluggable = WP_CONTENT_DIR . '/php-error.php' ;
if ( is_readable ( $php_error_pluggable ) ) {
require_once $php_error_pluggable ;
return ;
}
}
// Otherwise, display the default error template.
2019-09-14 21:18:55 -04:00
$this -> display_default_error_template ( $error , $handled );
Bootstrap/Load: Introduce fatal error handler.
This changeset introduces a `WP_Fatal_Error_Handler` class that detects fatal errors and displays a more user-friendly message about the site experiencing technical difficulties.
Websites that have custom requirements in that regard can implement their own fatal error handler by adding a `fatal-error-handler.php` drop-in that returns the handler instance to use, which must be based on a class that inherits `WP_Fatal_Error_Handler`. That handler will then be used in place of the default one. Alternatively, the fatal error handler feature can be completely disable through a constant `WP_DISABLE_FATAL_ERROR_HANDLER`.
Websites that would like to modify specifically the error template displayed in the frontend can add a `php-error.php` drop-in that works similarly to the existing `db-error.php` drop-in. For more granular customization, the fatal error handler also includes new filters `wp_should_handle_php_error`, `wp_php_error_message` and `wp_php_error_args`.
Props afragen, bradleyt, flixos90, ocean90, schlessera, SergeyBiryukov, spacedmonkey, timothyblynjacobs.
See #46130, #44458.
Built from https://develop.svn.wordpress.org/trunk@44962
git-svn-id: http://core.svn.wordpress.org/trunk@44793 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-03-21 12:03:51 -04:00
}
/**
* Displays the default PHP error template .
*
* This method is called conditionally if no 'php-error.php' drop - in is available .
*
* It calls { @ see wp_die ()} with a message indicating that the site is experiencing technical difficulties and a
* login link to the admin backend . The { @ see 'wp_php_error_message' } and { @ see 'wp_php_error_args' } filters can
* be used to modify these parameters .
*
* @ since 5.2 . 0
2019-09-14 21:18:55 -04:00
* @ since 5.3 . 0 The `$handled` parameter was added .
2019-03-26 20:16:51 -04:00
*
2019-09-14 21:18:55 -04:00
* @ param array $error Error information retrieved from `error_get_last()` .
* @ param true | WP_Error $handled Whether Recovery Mode handled the fatal error .
Bootstrap/Load: Introduce fatal error handler.
This changeset introduces a `WP_Fatal_Error_Handler` class that detects fatal errors and displays a more user-friendly message about the site experiencing technical difficulties.
Websites that have custom requirements in that regard can implement their own fatal error handler by adding a `fatal-error-handler.php` drop-in that returns the handler instance to use, which must be based on a class that inherits `WP_Fatal_Error_Handler`. That handler will then be used in place of the default one. Alternatively, the fatal error handler feature can be completely disable through a constant `WP_DISABLE_FATAL_ERROR_HANDLER`.
Websites that would like to modify specifically the error template displayed in the frontend can add a `php-error.php` drop-in that works similarly to the existing `db-error.php` drop-in. For more granular customization, the fatal error handler also includes new filters `wp_should_handle_php_error`, `wp_php_error_message` and `wp_php_error_args`.
Props afragen, bradleyt, flixos90, ocean90, schlessera, SergeyBiryukov, spacedmonkey, timothyblynjacobs.
See #46130, #44458.
Built from https://develop.svn.wordpress.org/trunk@44962
git-svn-id: http://core.svn.wordpress.org/trunk@44793 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-03-21 12:03:51 -04:00
*/
2019-09-14 21:18:55 -04:00
protected function display_default_error_template ( $error , $handled ) {
Bootstrap/Load: Introduce fatal error handler.
This changeset introduces a `WP_Fatal_Error_Handler` class that detects fatal errors and displays a more user-friendly message about the site experiencing technical difficulties.
Websites that have custom requirements in that regard can implement their own fatal error handler by adding a `fatal-error-handler.php` drop-in that returns the handler instance to use, which must be based on a class that inherits `WP_Fatal_Error_Handler`. That handler will then be used in place of the default one. Alternatively, the fatal error handler feature can be completely disable through a constant `WP_DISABLE_FATAL_ERROR_HANDLER`.
Websites that would like to modify specifically the error template displayed in the frontend can add a `php-error.php` drop-in that works similarly to the existing `db-error.php` drop-in. For more granular customization, the fatal error handler also includes new filters `wp_should_handle_php_error`, `wp_php_error_message` and `wp_php_error_args`.
Props afragen, bradleyt, flixos90, ocean90, schlessera, SergeyBiryukov, spacedmonkey, timothyblynjacobs.
See #46130, #44458.
Built from https://develop.svn.wordpress.org/trunk@44962
git-svn-id: http://core.svn.wordpress.org/trunk@44793 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-03-21 12:03:51 -04:00
if ( ! function_exists ( '__' ) ) {
wp_load_translations_early ();
}
if ( ! function_exists ( 'wp_die' ) ) {
require_once ABSPATH . WPINC . '/functions.php' ;
}
2019-05-15 14:19:51 -04:00
if ( ! class_exists ( 'WP_Error' ) ) {
require_once ABSPATH . WPINC . '/class-wp-error.php' ;
}
2019-09-14 21:18:55 -04:00
if ( true === $handled && wp_is_recovery_mode () ) {
2020-11-02 14:55:07 -05:00
$message = __ ( 'There has been a critical error on this website, putting it in recovery mode. Please check the Themes and Plugins screens for more details. If you just installed or updated a theme or plugin, check the relevant page for that first.' );
2019-09-14 21:18:55 -04:00
} elseif ( is_protected_endpoint () ) {
2020-11-02 14:55:07 -05:00
$message = __ ( 'There has been a critical error on this website. Please check your site admin email inbox for instructions.' );
2019-04-24 14:14:53 -04:00
} else {
2020-11-02 14:55:07 -05:00
$message = __ ( 'There has been a critical error on this website.' );
2019-04-24 14:14:53 -04:00
}
Bootstrap/Load: Introduce fatal error handler.
This changeset introduces a `WP_Fatal_Error_Handler` class that detects fatal errors and displays a more user-friendly message about the site experiencing technical difficulties.
Websites that have custom requirements in that regard can implement their own fatal error handler by adding a `fatal-error-handler.php` drop-in that returns the handler instance to use, which must be based on a class that inherits `WP_Fatal_Error_Handler`. That handler will then be used in place of the default one. Alternatively, the fatal error handler feature can be completely disable through a constant `WP_DISABLE_FATAL_ERROR_HANDLER`.
Websites that would like to modify specifically the error template displayed in the frontend can add a `php-error.php` drop-in that works similarly to the existing `db-error.php` drop-in. For more granular customization, the fatal error handler also includes new filters `wp_should_handle_php_error`, `wp_php_error_message` and `wp_php_error_args`.
Props afragen, bradleyt, flixos90, ocean90, schlessera, SergeyBiryukov, spacedmonkey, timothyblynjacobs.
See #46130, #44458.
Built from https://develop.svn.wordpress.org/trunk@44962
git-svn-id: http://core.svn.wordpress.org/trunk@44793 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-03-21 12:03:51 -04:00
2019-09-16 13:23:55 -04:00
$message = sprintf (
'<p>%s</p><p><a href="%s">%s</a></p>' ,
$message ,
2021-02-09 11:59:04 -05:00
/* translators: Documentation about troubleshooting. */
__ ( 'https://wordpress.org/support/article/faq-troubleshooting/' ),
__ ( 'Learn more about troubleshooting WordPress.' )
2019-09-16 13:23:55 -04:00
);
Bootstrap/Load: Introduce fatal error handler.
This changeset introduces a `WP_Fatal_Error_Handler` class that detects fatal errors and displays a more user-friendly message about the site experiencing technical difficulties.
Websites that have custom requirements in that regard can implement their own fatal error handler by adding a `fatal-error-handler.php` drop-in that returns the handler instance to use, which must be based on a class that inherits `WP_Fatal_Error_Handler`. That handler will then be used in place of the default one. Alternatively, the fatal error handler feature can be completely disable through a constant `WP_DISABLE_FATAL_ERROR_HANDLER`.
Websites that would like to modify specifically the error template displayed in the frontend can add a `php-error.php` drop-in that works similarly to the existing `db-error.php` drop-in. For more granular customization, the fatal error handler also includes new filters `wp_should_handle_php_error`, `wp_php_error_message` and `wp_php_error_args`.
Props afragen, bradleyt, flixos90, ocean90, schlessera, SergeyBiryukov, spacedmonkey, timothyblynjacobs.
See #46130, #44458.
Built from https://develop.svn.wordpress.org/trunk@44962
git-svn-id: http://core.svn.wordpress.org/trunk@44793 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-03-21 12:03:51 -04:00
$args = array (
'response' => 500 ,
'exit' => false ,
);
/**
* Filters the message that the default PHP error template displays .
*
* @ since 5.2 . 0
*
* @ param string $message HTML error message to display .
2019-03-26 20:16:51 -04:00
* @ param array $error Error information retrieved from `error_get_last()` .
Bootstrap/Load: Introduce fatal error handler.
This changeset introduces a `WP_Fatal_Error_Handler` class that detects fatal errors and displays a more user-friendly message about the site experiencing technical difficulties.
Websites that have custom requirements in that regard can implement their own fatal error handler by adding a `fatal-error-handler.php` drop-in that returns the handler instance to use, which must be based on a class that inherits `WP_Fatal_Error_Handler`. That handler will then be used in place of the default one. Alternatively, the fatal error handler feature can be completely disable through a constant `WP_DISABLE_FATAL_ERROR_HANDLER`.
Websites that would like to modify specifically the error template displayed in the frontend can add a `php-error.php` drop-in that works similarly to the existing `db-error.php` drop-in. For more granular customization, the fatal error handler also includes new filters `wp_should_handle_php_error`, `wp_php_error_message` and `wp_php_error_args`.
Props afragen, bradleyt, flixos90, ocean90, schlessera, SergeyBiryukov, spacedmonkey, timothyblynjacobs.
See #46130, #44458.
Built from https://develop.svn.wordpress.org/trunk@44962
git-svn-id: http://core.svn.wordpress.org/trunk@44793 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-03-21 12:03:51 -04:00
*/
2019-03-26 20:16:51 -04:00
$message = apply_filters ( 'wp_php_error_message' , $message , $error );
Bootstrap/Load: Introduce fatal error handler.
This changeset introduces a `WP_Fatal_Error_Handler` class that detects fatal errors and displays a more user-friendly message about the site experiencing technical difficulties.
Websites that have custom requirements in that regard can implement their own fatal error handler by adding a `fatal-error-handler.php` drop-in that returns the handler instance to use, which must be based on a class that inherits `WP_Fatal_Error_Handler`. That handler will then be used in place of the default one. Alternatively, the fatal error handler feature can be completely disable through a constant `WP_DISABLE_FATAL_ERROR_HANDLER`.
Websites that would like to modify specifically the error template displayed in the frontend can add a `php-error.php` drop-in that works similarly to the existing `db-error.php` drop-in. For more granular customization, the fatal error handler also includes new filters `wp_should_handle_php_error`, `wp_php_error_message` and `wp_php_error_args`.
Props afragen, bradleyt, flixos90, ocean90, schlessera, SergeyBiryukov, spacedmonkey, timothyblynjacobs.
See #46130, #44458.
Built from https://develop.svn.wordpress.org/trunk@44962
git-svn-id: http://core.svn.wordpress.org/trunk@44793 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-03-21 12:03:51 -04:00
/**
* Filters the arguments passed to { @ see wp_die ()} for the default PHP error template .
*
* @ since 5.2 . 0
*
* @ param array $args Associative array of arguments passed to `wp_die()` . By default these contain a
* 'response' key , and optionally 'link_url' and 'link_text' keys .
2019-03-26 20:16:51 -04:00
* @ param array $error Error information retrieved from `error_get_last()` .
Bootstrap/Load: Introduce fatal error handler.
This changeset introduces a `WP_Fatal_Error_Handler` class that detects fatal errors and displays a more user-friendly message about the site experiencing technical difficulties.
Websites that have custom requirements in that regard can implement their own fatal error handler by adding a `fatal-error-handler.php` drop-in that returns the handler instance to use, which must be based on a class that inherits `WP_Fatal_Error_Handler`. That handler will then be used in place of the default one. Alternatively, the fatal error handler feature can be completely disable through a constant `WP_DISABLE_FATAL_ERROR_HANDLER`.
Websites that would like to modify specifically the error template displayed in the frontend can add a `php-error.php` drop-in that works similarly to the existing `db-error.php` drop-in. For more granular customization, the fatal error handler also includes new filters `wp_should_handle_php_error`, `wp_php_error_message` and `wp_php_error_args`.
Props afragen, bradleyt, flixos90, ocean90, schlessera, SergeyBiryukov, spacedmonkey, timothyblynjacobs.
See #46130, #44458.
Built from https://develop.svn.wordpress.org/trunk@44962
git-svn-id: http://core.svn.wordpress.org/trunk@44793 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-03-21 12:03:51 -04:00
*/
2019-03-26 20:16:51 -04:00
$args = apply_filters ( 'wp_php_error_args' , $args , $error );
Bootstrap/Load: Introduce fatal error handler.
This changeset introduces a `WP_Fatal_Error_Handler` class that detects fatal errors and displays a more user-friendly message about the site experiencing technical difficulties.
Websites that have custom requirements in that regard can implement their own fatal error handler by adding a `fatal-error-handler.php` drop-in that returns the handler instance to use, which must be based on a class that inherits `WP_Fatal_Error_Handler`. That handler will then be used in place of the default one. Alternatively, the fatal error handler feature can be completely disable through a constant `WP_DISABLE_FATAL_ERROR_HANDLER`.
Websites that would like to modify specifically the error template displayed in the frontend can add a `php-error.php` drop-in that works similarly to the existing `db-error.php` drop-in. For more granular customization, the fatal error handler also includes new filters `wp_should_handle_php_error`, `wp_php_error_message` and `wp_php_error_args`.
Props afragen, bradleyt, flixos90, ocean90, schlessera, SergeyBiryukov, spacedmonkey, timothyblynjacobs.
See #46130, #44458.
Built from https://develop.svn.wordpress.org/trunk@44962
git-svn-id: http://core.svn.wordpress.org/trunk@44793 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-03-21 12:03:51 -04:00
2019-03-26 20:36:50 -04:00
$wp_error = new WP_Error (
'internal_server_error' ,
$message ,
array (
'error' => $error ,
)
);
Bootstrap/Load: Introduce fatal error handler.
This changeset introduces a `WP_Fatal_Error_Handler` class that detects fatal errors and displays a more user-friendly message about the site experiencing technical difficulties.
Websites that have custom requirements in that regard can implement their own fatal error handler by adding a `fatal-error-handler.php` drop-in that returns the handler instance to use, which must be based on a class that inherits `WP_Fatal_Error_Handler`. That handler will then be used in place of the default one. Alternatively, the fatal error handler feature can be completely disable through a constant `WP_DISABLE_FATAL_ERROR_HANDLER`.
Websites that would like to modify specifically the error template displayed in the frontend can add a `php-error.php` drop-in that works similarly to the existing `db-error.php` drop-in. For more granular customization, the fatal error handler also includes new filters `wp_should_handle_php_error`, `wp_php_error_message` and `wp_php_error_args`.
Props afragen, bradleyt, flixos90, ocean90, schlessera, SergeyBiryukov, spacedmonkey, timothyblynjacobs.
See #46130, #44458.
Built from https://develop.svn.wordpress.org/trunk@44962
git-svn-id: http://core.svn.wordpress.org/trunk@44793 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-03-21 12:03:51 -04:00
2019-03-26 20:16:51 -04:00
wp_die ( $wp_error , '' , $args );
Bootstrap/Load: Introduce fatal error handler.
This changeset introduces a `WP_Fatal_Error_Handler` class that detects fatal errors and displays a more user-friendly message about the site experiencing technical difficulties.
Websites that have custom requirements in that regard can implement their own fatal error handler by adding a `fatal-error-handler.php` drop-in that returns the handler instance to use, which must be based on a class that inherits `WP_Fatal_Error_Handler`. That handler will then be used in place of the default one. Alternatively, the fatal error handler feature can be completely disable through a constant `WP_DISABLE_FATAL_ERROR_HANDLER`.
Websites that would like to modify specifically the error template displayed in the frontend can add a `php-error.php` drop-in that works similarly to the existing `db-error.php` drop-in. For more granular customization, the fatal error handler also includes new filters `wp_should_handle_php_error`, `wp_php_error_message` and `wp_php_error_args`.
Props afragen, bradleyt, flixos90, ocean90, schlessera, SergeyBiryukov, spacedmonkey, timothyblynjacobs.
See #46130, #44458.
Built from https://develop.svn.wordpress.org/trunk@44962
git-svn-id: http://core.svn.wordpress.org/trunk@44793 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-03-21 12:03:51 -04:00
}
}