Add stack trace to failed plugin update error notifications

[tlloancy]

Problem

When a plugin update fails, WordPress sends an email notification (example below) indicating the failure, but no detailed error information is provided. Additionally, the debug log (wp-content/debug.log) remains empty, making it difficult to diagnose the cause of the failure.

Example Email Notification:

Bonjour ! Certaines mises à jour d’extensions ont échoué sur votre site situé à l’adresse ​https://yspania.com. [...] Les extensions suivantes n’ont pas pu être mises à jour. [...] - WooPayments (de la version 10.1.0 vers 10.1.1) : ​https://wordpress.org/plugins/woocommerce-payments/

Proposed Enhancement

Add a stack trace or detailed error information (e.g., PHP error type, file, and line number) to the email notifications and debug log for failed plugin updates. This would help site administrators identify and troubleshoot issues more effectively.

Impact

Without detailed error information, diagnosing plugin update failures is challenging, especially for non-technical users. This can lead to prolonged downtime, security risks, or reliance on external support.

Suggested Implementation

Modify the plugin update process (likely in wp-admin/includes/update.php or related files) to capture and include PHP error details and a stack trace in:

• The email notification sent to the site administrator.
• The WordPress debug log when WP_DEBUG_LOG is enabled.

Consider using PHP's debug_backtrace() or similar functions to generate the stack trace and include it only when debugging is enabled to avoid exposing sensitive information in production environments.

Steps to Reproduce

1. Enable WP_DEBUG and WP_DEBUG_LOG in wp-config.php.
2. Trigger a plugin update that fails (e.g., due to a timeout, permissions issue, or fatal error).
3. Check the email notification and wp-content/debug.log for error details.
4. Observe that no stack trace or detailed error information is provided.

Additional Notes

This enhancement would align with WordPress's goal of improving developer and administrator experience by providing better tools for debugging. It could also reduce the number of support requests on forums like ​https://wpfr.net/support.

[tlloancy]

To provide additional context for this enhancement request, I've observed a specific case in my own custom/low-usage plugin, SlideCraft Reborn (a slider creation tool for WordPress), where a cron task failed silently during a plugin update attempt. The issue stemmed from a call to wp_cache_flush() in the plugin's code, which interrupted the cron job without triggering any detectable error in WordPress's core mechanisms.

This silent failure went completely unnoticed in the update process: no entry appeared in the debug log (wp-content/debug.log), and the email notification for the failed update provided zero details beyond the basic failure message. Since SlideCraft Reborn is a niche plugin with very few installations (almost no users), there are no community reports or widespread discussions about this, making it even harder to diagnose without manual deep dives into server logs or code.

This underscores the need for enhanced error reporting, such as automatically including a stack trace in:

• The cron task execution logs (when WP_DEBUG_LOG is enabled).
• Failed update email notifications.
• Potentially, a new hook or filter for plugins to opt-in to better error capturing.

Without this, developers of lesser-known plugins (or custom ones) are left guessing, which can lead to overlooked security/maintenance issues.

Steps to Reproduce (on a test site with SlideCraft Reborn installed):

1. Enable WP_DEBUG and WP_DEBUG_LOG in wp-config.php.
2. Install/activate SlideCraft Reborn (version with the wp_cache_flush() call, e.g., during a cron-related hook).
3. Trigger a plugin update or let a cron task run that invokes the plugin's code.
4. Observe the cron failure (e.g., via WP-CLI wp cron test or server monitoring).
5. Check the debug log and any update failure email: no stack trace or error details are present.

If helpful, I can provide a minimal code snippet from SlideCraft Reborn demonstrating the wp_cache_flush() trigger, or set up a test environment for reproduction.

This real-world example from a low-profile plugin supports prioritizing the proposed enhancement to make WordPress more robust for all extension developers.

[afragen]

Can I assume that after the update failure the plugin still shows an update available?

If this is the case, what happens during a manual plugin update?

[tlloancy]

@afragen: The auto-update for WooPayments (10.1.0 → 10.1.1) on ​https://yspania.com failed at 09:49:57 UTC (email: "Certaines mises à jour d’extensions ont échoué"), with no error details or stack trace in the email and an empty debug.log (WP_DEBUG_LOG enabled). Server logs confirm no downtime, DDoS, or OOM killer issues (wp-cron ran fine). The second attempt at 20:49:02 UTC succeeded (email: "Certaines extensions ont été mises à jour"). This random failure-then-success, with no debug info, mirrors my SlideCrafter Reborn case and highlights the need for stack traces in emails/logs to diagnose unpredictable issues. Can explore test scenarios if helpful.