Commit Graph

20 Commits

Author SHA1 Message Date
Sergey Biryukov
2fdd20da49 Site Health: Link to the support article on troubleshooting in "There has been a critical error" message.
This page is more geared towards users than the one on debugging, which is more developer-oriented.

Props audrasjb, Clorith, Ipstenu.
Fixes #52392.
Built from https://develop.svn.wordpress.org/trunk@50272


git-svn-id: http://core.svn.wordpress.org/trunk@49917 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2021-02-09 16:59:04 +00:00
Helen Hou-Sandí
da4b76c6b3 Site Health: Site errors are for *this* site, not necessarily *your* site.
Props techboyg5, Clorith, audrasjb.
Fixes #51524.

Built from https://develop.svn.wordpress.org/trunk@49480


git-svn-id: http://core.svn.wordpress.org/trunk@49239 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2020-11-02 19:55:07 +00:00
Sergey Biryukov
f7da44c8d2 Upgrade/Install: Rename wp_in_maintenance_mode() to wp_is_maintenance_mode(), for consistency with wp_is_recovery_mode().
While the former name might be a bit more accurate, the latter matches the existing naming pattern.

Follow-up to [47623].

Fixes #49959.
Built from https://develop.svn.wordpress.org/trunk@47871


git-svn-id: http://core.svn.wordpress.org/trunk@47646 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2020-05-31 19:54:24 +00:00
Sergey Biryukov
86ac5e1432 Site Health: Do not trigger the fatal error handler while updates are being installed.
Triggering the error handler during updates may cause false positives. For example, updates may temporarily "fail" while files are moved around, but work fine once completed. Sending emails about temporary failures would just be confusing to the recipient.

Props Clorith, airamerica.
Fixes #48964.
Built from https://develop.svn.wordpress.org/trunk@47768


git-svn-id: http://core.svn.wordpress.org/trunk@47544 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2020-05-06 14:38:17 +00:00
Sergey Biryukov
38e37b83df Site Health: Remove esc_url() used on "Debugging in WordPress" article URL in WP_Fatal_Error_Handler::display_default_error_template().
The function may not be available in some contexts, for example if a fatal error happens in `advanced-cache.php` drop-in.

Props rob006.
Fixes #49709.
Built from https://develop.svn.wordpress.org/trunk@47515


git-svn-id: http://core.svn.wordpress.org/trunk@47290 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2020-03-27 18:22:06 +00:00
Sergey Biryukov
001ffe81fb Docs: Improve inline comments per the documentation standards.
Includes minor code layout fixes for better readability.

See #48303.
Built from https://develop.svn.wordpress.org/trunk@47122


git-svn-id: http://core.svn.wordpress.org/trunk@46922 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2020-01-29 00:45:18 +00:00
Sergey Biryukov
a3e747990c Site Health: Add a link to "Debugging in WordPress" support article to fatal PHP error handler's default message.
Props garrett-eclipse, tobifjellner, dkarfa, hareesh-pillai.
Fixes #47681.
Built from https://develop.svn.wordpress.org/trunk@46151


git-svn-id: http://core.svn.wordpress.org/trunk@45963 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-09-16 17:23:55 +00:00
Sergey Biryukov
142efedee0 Site Health: Show a more specific fatal error message when in Recovery Mode with headers already sent.
Props garrett-eclipse, TimothyBlynJacobs, mukesh27, marybaum, afragen, Clorith, mdwolinski, SergeyBiryukov.
Fixes #47321.
Built from https://develop.svn.wordpress.org/trunk@46119


git-svn-id: http://core.svn.wordpress.org/trunk@45931 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-09-15 01:18:55 +00:00
desrosj
ac095904da Bootstrap/Load: Prevent PHP errors when a drop-in triggers fatal error protection.
When a drop-in (such as `advanced-cache.php`) contains a PHP error, additional PHP errors are caused when displaying the error protection screen because `load_default_textdomain()` and `WP_Error` are not yet available.

Though recovery mode is not supported for `mu-plugins` and drop-ins, fatal error protection is. This change ensures the error screen is displayed when a fatal error is encountered within a drop-in and not a white screen.

Props TimothyBlynJacobs, spacedmonkey, daxelrod.
Fixes #47265.
Built from https://develop.svn.wordpress.org/trunk@45311


git-svn-id: http://core.svn.wordpress.org/trunk@45122 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-05-15 18:19:51 +00:00
desrosj
d48b709071 Bootstrap/Load: Ensure recovery link email and related notices are properly translated.
When recovery mode is triggered before the site’s locale has been initialized, the message displayed to the user and the email sent to the site administrator with the recovery mode link are always rendered in `en_US`. This change ensures the site’s locale is used even when an error happens early in the loading process.

Reviewed by swissspidy, SergeyBiryukov, and desrosj.

Props wolly, TimothyBlynJacobs, fierevere.
Fixes #47093.
Built from https://develop.svn.wordpress.org/trunk@45277


git-svn-id: http://core.svn.wordpress.org/trunk@45086 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-05-02 10:53:52 +00:00
Sergey Biryukov
54c7c76836 Bootstrap/Load: Modify the fatal error template to indicate to the user that they can check the admin email address for further instructions.
Props spacedmonkey, TimothyBlynJacobs.
Fixes #46950.
Built from https://develop.svn.wordpress.org/trunk@45263


git-svn-id: http://core.svn.wordpress.org/trunk@45072 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-04-24 18:14:53 +00:00
Felix Arntz
f1352827f8 General: Display fatal error handler notice in admin backend even if headers have been sent.
This ensures that at least for the admin, which is more predictable than the frontend, the user-friendlier error notice from the fatal error handler still shows if a runtime fatal error happens within the page generation process.

Props axaak.
Fixes #46811.

Built from https://develop.svn.wordpress.org/trunk@45210


git-svn-id: http://core.svn.wordpress.org/trunk@45019 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-04-16 04:38:51 +00:00
Felix Arntz
6d58109b09 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 15:20:55 +00:00
Sergey Biryukov
ada13d2ffd PHPCS: Fix WPCS violations in [45023].
See #46620.
Built from https://develop.svn.wordpress.org/trunk@45025


git-svn-id: http://core.svn.wordpress.org/trunk@44834 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-03-27 00:36:50 +00:00
Sergey Biryukov
455dccbc00 Bootstrap/Load: In fatal error handler, pass the error information through to error template and associated filters: wp_php_error_message, wp_php_error_args.
This allows the custom error handler and default error message filters to inspect the error and perform logic based on its properties.

Props johnbillion.
Fixes #46620.
Built from https://develop.svn.wordpress.org/trunk@45023


git-svn-id: http://core.svn.wordpress.org/trunk@44832 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-03-27 00:16:51 +00:00
Sergey Biryukov
3f6a9eb0e3 Bootstrap/Load: Always run the fatal error handler at shutdown, but don't display the PHP error template once headers are sent.
If a fatal error occurs midway through a page load, or in a REST API request, it still needs to be handled internally for the recovery mode, but the custom message may conflict with already rendered output, e.g. by displaying HTML markup in an XML or JSON request.

Props spacedmonkey, flixos90, TimothyBlynJacobs.
Fixes #45989. See #44458.
Built from https://develop.svn.wordpress.org/trunk@45014


git-svn-id: http://core.svn.wordpress.org/trunk@44823 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-03-26 20:30:53 +00:00
Felix Arntz
3a77265148 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 21:53:51 +00:00
Felix Arntz
dcb9d7cc7b 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 16:03:51 +00:00
Felix Arntz
92c3c46abe Bootstrap/Load: Revert fatal error recovery mechanism from 5.1 to polish for 5.2.
Due to the high number of follow-up tickets and associated security concerns, it was decided to reschedule the fatal error recovery feature for WordPress 5.2, in order to address these issues properly. The feature will continue to be developed, with iterations being merged into trunk early in the 5.2 release cycle.

Fixes #46141. See #44458, #45932, #45940, #46038, #46047, #46068.

Built from https://develop.svn.wordpress.org/trunk@44717


git-svn-id: http://core.svn.wordpress.org/trunk@44548 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-01-30 11:01:52 +00:00
Felix Arntz
7daa39eb1d Bootstrap/Load: Change shutdown handler naming to final fatal error handler and allow disabling the handler entirely via a constant.
The `WP_Shutdown_Handler` name plus related function names were premature when originally committed, as there can be multiple shutdown handlers in PHP, and WordPress makes use of that feature. This changeset modifies the name to a more appropriate `WP_Fatal_Error_Handler`, and related to that changes the following names:

* The drop-in to override the handler is now called `fatal-error-handler.php`.
* The internal function `wp_register_premature_shutdown_handler` is now called `wp_register_fatal_error_handler()`.

In addition to these naming changes, a new constant `WP_DISABLE_FATAL_ERROR_HANDLER` is introduced that can be set in `wp-config.php` to entirely disable the fatal error handler. That constant's value is and should be accessed indirectly via a new `wp_is_fatal_error_handler_enabled()` function and is filterable via a new `wp_fatal_error_handler_enabled` hook. Note that disabling the fatal error handler will skip the new functionality entirely, including the potentially used `fatal-error-handler.php` drop-in.

The new set of constant, filter and function provide for an easier-to-use mechanism to disable the fatal error handler altogether, rather than requiring developers to implement a drop-in for purely that purpose.

Props afragen, flixos90, joyously, knutsp, markjaquith, ocean90, schlessera, spacedmonkey.
Fixes #46047. See #44458.

Built from https://develop.svn.wordpress.org/trunk@44674


git-svn-id: http://core.svn.wordpress.org/trunk@44505 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2019-01-21 20:15:50 +00:00