Administration: Add last fatal PHP error to auto-update failure emails #10445
Conversation
Admins must know *why* an update failed — especially when rollback hides the crash. ### Changes - Captures fatal error in `has_fatal_error()` via `error_get_last()` or `debug.log` - Stores in global transient `wp_last_fatal_error` - Adds to failure email with clear English message - No performance impact — only runs on failure - Fully backward compatible ### Testing - Tested on WP 6.8.3 with memory exhaustion (WooCommerce) - Email includes exact error: `PHP Fatal error: Allowed memory size... in class-wc-autoloader.php on line 58` FIXES #64155
- Replace `file()` + `array_reverse()` with backward line-by-line reading - Safe for BIG debug.log - Use `E_*` constants for clarity Fixes #64155
|
Hi @tlloancy! 👋 Thank you for your contribution to WordPress! 💖 It looks like this is your first pull request to No one monitors this repository for new pull requests. Pull requests must be attached to a Trac ticket to be considered for inclusion in WordPress Core. To attach a pull request to a Trac ticket, please include the ticket's full URL in your pull request description. Pull requests are never merged on GitHub. The WordPress codebase continues to be managed through the SVN repository that this GitHub repository mirrors. Please feel free to open pull requests to work on any contribution you are making. More information about how GitHub pull requests can be used to contribute to WordPress can be found in the Core Handbook. Please include automated tests. Including tests in your pull request is one way to help your patch be considered faster. To learn about WordPress' test suites, visit the Automated Testing page in the handbook. If you have not had a chance, please review the Contribute with Code page in the WordPress Core Handbook. The Developer Hub also documents the various coding standards that are followed:
Thank you, |
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
- Use Yoda conditions - Use single quotes for simple strings - Use array() instead of [] - Remove trailing whitespace - Use E_* constants
|
Just letting you know I’ll review and comment here. |
| if ( $last_error && in_array( $last_error['type'], array( E_ERROR, E_PARSE, E_COMPILE_ERROR, E_USER_ERROR ) ) ) { | ||
| $fatal_error = "PHP Fatal error: {$last_error['message']} in {$last_error['file']} on line {$last_error['line']}"; | ||
| } else { | ||
| $log_file = WP_CONTENT_DIR . '/debug.log'; |
There was a problem hiding this comment.
This should use whatever the error_log is set to in the PHP config.
| $log_file = WP_CONTENT_DIR . '/debug.log'; | |
| $log_file = ini_get( 'error_log' ); |
For another approach at parsing the error log, consider this code from the AMP plugin: https://github.com/ampproject/amp-wp/blob/2.5.4/src/Support/SupportData.php#L351-L410
| } | ||
|
|
||
| if ( $fatal_error ) { | ||
| set_transient( 'wp_last_fatal_error', $fatal_error, 5 * MINUTE_IN_SECONDS ); |
There was a problem hiding this comment.
Perhaps the transient's name should be specific to the updater to distinguish it from any other general captures of the last fatal error (if we ever do that). So maybe like wp_updater_last_fatal_error
| if ( defined( 'WP_DEBUG' ) && WP_DEBUG && 'fail' === $type ) { | ||
| $fatal_error = get_transient( 'wp_last_fatal_error' ); | ||
| if ( $fatal_error ) { | ||
| $email['body'] .= "\n\n=== LAST FATAL PHP ERROR ===\n"; |
There was a problem hiding this comment.
This should be translated:
| $email['body'] .= "\n\n=== LAST FATAL PHP ERROR ===\n"; | |
| $email['body'] .= "\n\n=== " . __( 'LAST FATAL PHP ERROR' ) . " ===\n"; |
| */ | ||
| $email = apply_filters( 'auto_plugin_theme_update_email', $email, $type, $successful_updates, $failed_updates ); | ||
|
|
||
| if ( defined( 'WP_DEBUG' ) && WP_DEBUG && 'fail' === $type ) { |
There was a problem hiding this comment.
The constant is always defined in default-constants.php so the initial check can be removed:
| if ( defined( 'WP_DEBUG' ) && WP_DEBUG && 'fail' === $type ) { | |
| if ( WP_DEBUG && 'fail' === $type ) { |
|
|
||
| $last_error = error_get_last(); | ||
| if ( $last_error && in_array( $last_error['type'], array( E_ERROR, E_PARSE, E_COMPILE_ERROR, E_USER_ERROR ) ) ) { | ||
| $fatal_error = "PHP Fatal error: {$last_error['message']} in {$last_error['file']} on line {$last_error['line']}"; |
There was a problem hiding this comment.
Should this be translated? I suppose it wouldn't be translated in the error log either.
- Use ini_get('error_log') with safe fallback
- Specific transient: wp_updater_last_fatal_error
- Remove defined('WP_DEBUG')
- Translate header only
- 0 RAM, tested on 400MB+ logs
Props: @westonruter, @knutsp
3 participants
Admins must know why an update failed — especially when rollback hides the crash.
Changes
has_fatal_error()viaerror_get_last()ordebug.logwp_last_fatal_errordebug.logProof (tested on 4MB log):