Commit Graph

26 Commits

Author SHA1 Message Date
Sergey Biryukov
fac2864841 Docs: Document the $wp_locale global in WP_Fatal_Error_Handler::handle().
Follow-up to [45277].

Props viralsampat.
See #60021.
Built from https://develop.svn.wordpress.org/trunk@57194


git-svn-id: http://core.svn.wordpress.org/trunk@56705 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-12-16 09:38:25 +00:00
audrasjb
418a21fdbc Help/About: Use the new /documentation/ URLs for HelpHub links in WordPress Admin.
As `https://wordpress.org/support/` was redirected to `https://wordpress.org/documentation/`, this changeset replaces various `/support/article/*` links with `/documentation/article/*` to avoid an extra redirect.

This also updates links to Support Forums by replacing `https://wordpress.org/support/` URLs with `https://wordpress.org/support/forums/`.

Props SergeyBiryukov, audrasjb, dhrupo, hasanmisbah, sakibmd, sabernhardt.
See #57726.

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


git-svn-id: http://core.svn.wordpress.org/trunk@54945 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-02-23 10:38:21 +00:00
Sergey Biryukov
c03305852e Code Modernization: Add AllowDynamicProperties attribute to all (parent) classes.
Dynamic (non-explicitly declared) properties are deprecated as of PHP 8.2 and are expected to become a fatal error in PHP 9.0.

There are a number of ways to mitigate this:
* If it is an accidental typo for a declared property: fix the typo.
* For known properties: declare them on the class.
* For unknown properties: add the magic `__get()`, `__set()`, et al. methods to the class or let the class extend `stdClass` which has highly optimized versions of these magic methods built in.
* For unknown ''use'' of dynamic properties, the `#[AllowDynamicProperties]` attribute can be added to the class. The attribute will automatically be inherited by child classes.

Trac ticket #56034 is open to investigate and handle the third and fourth type of situations, however it has become clear this will need more time and will not be ready in time for WP 6.1.

To reduce “noise” in the meantime, both in the error logs of WP users moving onto PHP 8.2, in the test run logs of WP itself, in test runs of plugins and themes, as well as to prevent duplicate tickets from being opened for the same issue, this commit adds the `#[AllowDynamicProperties]` attribute to all “parent” classes in WP.

The logic used for this commit is as follows:
* If a class already has the attribute: no action needed.
* If a class does not `extend`: add the attribute.
* If a class does `extend`:
 - If it extends `stdClass`: no action needed (as `stdClass` supports dynamic properties).
 - If it extends a PHP native class: add the attribute.
 - If it extends a class from one of WP's external dependencies: add the attribute.
* In all other cases: no action — the attribute should not be needed as child classes inherit from the parent.

Whether or not a class contains magic methods has not been taken into account, as a review of the currently existing magic methods has shown that those are generally not sturdy enough and often even set dynamic properties (which they should not). See the [https://www.youtube.com/watch?v=vDZWepDQQVE live stream from August 16, 2022] for more details.

This commit only affects classes in the `src` directory of WordPress core.
* Tests should not get this attribute, but should be fixed to not use dynamic properties instead. Patches for this are already being committed under ticket #56033.
* While a number bundled themes (2014, 2019, 2020, 2021) contain classes, they are not a part of this commit and may be updated separately.

Reference: [https://wiki.php.net/rfc/deprecate_dynamic_properties PHP RFC: Deprecate dynamic properties].

Follow-up to [53922].

Props jrf, hellofromTonya, markjaquith, peterwilsoncc, costdev, knutsp, aristath.
See #56513, #56034.
Built from https://develop.svn.wordpress.org/trunk@54133


git-svn-id: http://core.svn.wordpress.org/trunk@53692 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2022-09-12 15:47:14 +00:00
Clorith
00fb102dae Site Health: Improve the fatal error handling text in multisite scenarios.
The fatal error handler is responsible for providing a more user-friendly page to visitors if a site would normally encounter a fatal error, informing them of the next steps to access recovery mode (where applicable).

Those next steps would be to check the email address for the site administrator, but this was only the case for single site installs; In a multisite scenario, no email is sent.

This changes the text to account for that, still informing site administrators to check their email if it is a single site, but for multisite directing users to reach out to their site administrator for further assistance, so that they may take appropriate action.

Props rkaiser0324, Clorith.
Fixes #48929.
Built from https://develop.svn.wordpress.org/trunk@53951


git-svn-id: http://core.svn.wordpress.org/trunk@53510 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2022-08-28 19:51:09 +00:00
John Blackbourn
beac9601fa Docs: Corrections and improvements to docblocks for function and hooks relating to fatal error handling.
See #54729

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


git-svn-id: http://core.svn.wordpress.org/trunk@52905 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2022-04-29 19:17:11 +00:00
Aaron Jorbin
5fac9d83a9 Booststrap/Load: Only reference recovery mode email when it can be sent.
The recovery mode email is sent from within the WP_Recovery_Mode::handle_error() method, but that method is only called by the fatal error handler if WP_Recovery_Mode has been initialized. This adjusts the message to only say the email has been sent if it can be sent.

Props reynhartono, stevegrunwell for initial plan.
Fixes #52560.

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


git-svn-id: http://core.svn.wordpress.org/trunk@50685 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2021-06-05 15:46:57 +00:00
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