[wp-trac] [WordPress Trac] #64155: Add stack trace to failed plugin update error notifications

[WordPress Trac]

#64155: Add stack trace to failed plugin update error notifications
-------------------------------------+-------------------------------------
 Reporter:  tlloancy                 |       Owner:  (none)
     Type:  enhancement              |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Upgrade/Install          |     Version:  6.8.3
 Severity:  normal                   |  Resolution:
 Keywords:  needs-testing needs-     |     Focuses:  administration, php-
  patch                              |  compatibility
-------------------------------------+-------------------------------------

Comment (by 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64155#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform