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.

[afragen]

@tlloancy my question isn't that it fails. It's whether the rollback is working and the site still shows an update available.

[tlloancy]

@afragen: Yes — after the failed auto-update at 09:49:57 UTC:

• "Mettre à jour maintenant" link was present in the update row.
• Update still showed as scheduled ("planifiée dans X heures").
• I did NOT click manual update — let the next auto-run do it.
• It succeeded at 20:49:02 UTC.

[afragen]

@tlloancy I consider this a success and exactly what’s supposed to happen.

I will tell you that if you have WP_DEBUG set to true you will see more in your debug.log.

I have seen seemingly silent PHP Fatals in the log, probably caused by some script trying to access pages and functions directly. If these occur during the auto-update process the PHP Fatal can stop any running process and the update will fail.

All this to say, if auto-update is left alone it is likely to succeed either on the first or second attempt.

[tlloancy]

just now
@afragen Here is hard proof from another real production site — two consecutive auto-update failures of the same plugin, both with:
phpdefine( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
Result:

wp-content/debug.log → completely empty
No PHP error, no timeout, no memory issue
Manual update works instantly

Plugin in question: Newsletter
→ Version 9.0.5 → 9.0.6

Failure #1 – 2025-10-21 15:08:13
textSubject: [GATASYA YOGA] Certaines mises à jour d’extensions ont échoué
Recipient: contact@…

Email body (via WP Mail Logging iframe preview):
"Les extensions suivantes n’ont pas pu être mises à jour : Newsletter"
No error code. No reason. No stack trace.

Failure #2 – 2025-10-22 03:19:37
textSubject: [GATASYA YOGA] Certaines mises à jour d’extensions ont échoué
Recipient: contact@…

Same email. Same plugin: Newsletter
Same silence in logs
Retry later → succeeded
Manual update from admin → instant success

Source: WP Mail Logging Plugin

<!-- Email #1 -->
<div class="wp-mail-logging-modal-row-value">2025-10-21 15:08:13</div>
<div class="wp-mail-logging-modal-row-value">[GATASYA YOGA] Certaines mises à jour d’extensions ont échoué</div>

<!-- Email #2 -->
<div class="wp-mail-logging-modal-row-value">2025-10-22 3:19:37</div>
<div class="wp-mail-logging-modal-row-value">[GATASYA YOGA] Certaines mises à jour d’extensions ont échoué</div>

No WP_Error code. No message. No file/line. No stack trace.

This is not a fatal PHP error
→ Fatals are logged with WP_DEBUG_LOG
→ These are not
This is not a download/network failure
→ download_failed → logged
→ Here: total silence

And then the manual update works, Which of course does'nt help at all the comprehension

Newsletter
Désactiver | Traduire
L’extension Newsletter permet de créer votre propre liste d’abonnés, d’envoyer des newsletters en masse, et de construire votre réseau professionnel. Avant de mettre à jour, visitez cette page, pour connaître les derniers changements.

Version 9.0.6 | Par Stefano Lissa & The Newsletter Team | Afficher les détails
Désactiver les mises à jour auto
Mis à jour !

Proposed Fix (debug-only, zero production impact) Something along this line:

// File: wp-admin/includes/class-wp-automatic-updater.php
// After: $result = $upgrader->upgrade( $plugin );

if ( is_wp_error( $result ) ) {
    $plugin     = $this->skin->plugin;
    $error_msg  = $result->get_error_message();
    $error_code = $result->get_error_code();

    // 1. Log to debug.log (only if enabled)
    if ( defined( 'WP_DEBUG_LOG' ) && WP_DEBUG_LOG ) {
        $trace = ( defined( 'WP_DEBUG' ) && WP_DEBUG )
            ? "\nStack trace:\n" . ( new Exception() )->getTraceAsString()
            : '';

        error_log( sprintf(
            "[Auto-Update Failure] Plugin: %s | Code: %s | Message: %s%s",
            $plugin,
            $error_code,
            $error_msg,
            $trace
        ) );
    }

    // 2. Enhanced email (admin-only)
    $debug_info = ( defined( 'WP_DEBUG' ) && WP_DEBUG )
        ? "\n\nDebug: {$error_msg} (Code: {$error_code})"
        : '';

    $this->send_email( 'failure', $plugin, $debug_info );
}

Conclusion:
Rollback + retry = does not fix it
Manual update = required to resolve
Debugging = impossible

[tlloancy]

@afragen

Additional evidence uploaded — 3 screenshots attached to this ticket to fully support the silent failure claim:

---

### Attached Screenshots:

1. screenshot-1-email-failure-1.png → WP Mail Logging: Email #1 (2025-10-21 15:08:13) → Subject: Certaines mises à jour d’extensions ont échoué → Body clearly lists: "Newsletter"

2. screenshot-2-email-failure-2.png → WP Mail Logging: Email #2 (2025-10-22 03:19:37) → Same subject, same plugin: Newsletter → No error details, no stack trace

3. screenshot-3-plugin-updated-manually.png → WordPress admin → Plugins page → Newsletter now at Version 9.0.6 → Status: Mis à jour ! → Only after manual update — auto-updates failed twice

---

All with:
`php
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );

[afragen]

@tlloancy why don't you put your debugging code in one of your site displaying the problem and get some data? Perhaps then we can get to the root of the problem.

[afragen]

@tlloancy if you want I wrote a single file plugin that will fill your debug.log with all sorts of data. I have to warn you that there will be mountains of stuff to sort through.

​https://gist.github.com/afragen/a09b52047bf1d7f11b622941678824cc

[tlloancy]

@afragen: Thanks for the plugin — I’ll test it on a staging copy of ​https://yspania.com or ​https://gatasya-yoga.com to capture the next failure without risking production.

But this is exactly my point:

• Admins shouldn’t need a custom debug plugin to understand *why* an auto-update failed.
• WP_DEBUG_LOG is on → debug.log stays empty.
• Failure email → zero details.
• Manual update works, auto-retry works later → but no trace of the root cause.

Your tool is great for developers, but core should log stack traces by default in failure emails/logs — so any admin can diagnose issues like:

• Silent fatal in a plugin (wp_cache_flush() killing cron)
• Timeout / memory
• Filesystem lock

And maybe even they can help themselves after that with plugins such as WP Control for instance.

I’ll run your plugin on staging and share results if a failure occurs.
But this ticket is about making WordPress *self-diagnosing* for all users, not just those who can install debug tools.

[afragen]

Unfortunately I don't think most users will understand a stacktrace. They really just want to know did it work or not.

[tlloancy]

@afragen

Thanks for the debug plugin — it worked perfectly on the production site (no staging needed this time). Here's hard evidence from debug.log during the exact failed auto-update of *Payment Plugins for Stripe WooCommerce* (3.3.94 → 3.3.95) on 2025-10-30 at 08:48 UTC (email sent at 09:48 local time).

---

### Key Log Excerpt (filtered to 08:48)

log
[30-Oct-2025 08:48:30 UTC] Plugin 'woo-stripe-payment' has been upgraded.
[30-Oct-2025 08:48:32 UTC] Scraping home page...
[30-Oct-2025 08:48:32 UTC] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 32768 bytes) in /var/lib/wordpress/wp-content/plugins/advanced-custom-fields/includes/fields/class-acf-field-wysiwyg.php on line 375
[30-Oct-2025 08:48:33 UTC] wp_error_added 'plugin_update_fatal_error_rollback_successful'
[30-Oct-2025 08:48:33 UTC] La mise à jour de « woo-stripe-payment » contenait une erreur fatale. La version précédente a été restaurée.

---

### What Happened

1. Update succeeded → files replaced.
2. Post-update check: WordPress scraped the homepage (Scraping home page...).
3. ACF WYSIWYG fields loaded → memory exhausted at 128 MB.
4. PHP fatal error → process killed.
5. Rollback triggered → version restored.
6. Email sent: *"Certaines mises à jour d’extensions ont échoué"* → zero details.
7. debug.log (without your plugin): completely empty (even with WP_DEBUG_LOG = true).

---

### Why This Proves the Ticket

• Silent failure: No WP_Error code, no message, no stack trace in email or default log.
• Fatal error not captured: Occurs in a cron HTTP child process → bypasses debug.log.
• Manual update works: No scraping → no memory issue.
• Rollback works, but admin is blind → cannot fix root cause (low memory_limit + heavy ACF frontend).

---

### Proposed Fix (improved version)

// wp-admin/includes/class-wp-automatic-updater.php
// After: $result = $upgrader->upgrade( $plugin );

if ( is_wp_error( $result ) || doing_action( 'wp_maybe_auto_update' ) ) {
    $last_error = error_get_last();
    $fatal_info = $last_error && $last_error['type'] === E_ERROR
        ? "\nFatal Error: {$last_error['message']} in {$last_error['file']}:{$last_error['line']}"
        : '';

    // 1. Log (only if enabled)
    if ( defined( 'WP_DEBUG_LOG' ) && WP_DEBUG_LOG ) {
        $trace = ( defined( 'WP_DEBUG' ) && WP_DEBUG )
            ? "\nStack trace:\n" . ( new Exception() )->getTraceAsString()
            : '';
        error_log( "[Auto-Update Failure] Plugin: {$this->skin->plugin} | {$result->get_error_message()}{$fatal_info}{$trace}" );
    }

    // 2. Enhanced email
    $debug_info = ( defined( 'WP_DEBUG' ) && WP_DEBUG )
        ? "\n\n--- Debug ---\nError: {$result->get_error_message()}{$fatal_info}"
        : '';
    $this->send_email( 'failure', $this->skin->plugin, $debug_info );
}

• Uses error_get_last() → captures real fatal.
• Only in debug mode → no production risk.
• Works for all silent failures (memory, timeout, etc.).

---

### Attachments

1. Full debug.log → [debug.log.txt](​https://filebin.net/hzdhnzxqlbnu7xmm)
2. Email screenshot → [email-failure-screenshot.png](​https://ibb.co/Cp2WVvx4)
3. Debug.log relevant part → [wp-config-debug.png](​https://ibb.co/FqLBYVvR)

---

This is not just a retry issue.
This is a UX + debugging failure in core.
Admins must know *why* an update failed — especially when rollback hides the crash.

Ready to open a PR if needed.
Let me know how to help move this forward.

---

Keywords: has-patch needs-testing
Focuses: administration, php-compatibility

[afragen]

@tlloancy this is consistent with what I said about silent PHP fatals occurring during the auto-update. The assumption is that the shouldn't always be present and eventually the auto-update succeeds assuming the update doesn't contain a PHP fatal.

That said. Why don't you try testing your patch and let us know the results. If it works to your satisfaction then make a PR. I'll be happy to review.

[tlloancy]

@afragen Thank you for the feedback.

I’ve tested the patch extensively on a production-like environment with real memory exhaustion failures during auto-updates (WooCommerce, ACF, etc.).

### Results:

• Fatal error is captured in has_fatal_error() via error_get_last() or debug.log.
• Stored in a global transient (wp_last_fatal_error) before rollback.
• Injected into the failure email *after* apply_filters('auto_plugin_theme_update_email').
• No performance impact — only runs on failure.
• No file I/O — uses WordPress transients (clean, safe, atomic).
• Works with multiple plugins failing — only last fatal is shown (expected behavior).
• English message, no textdomain needed (technical debug output).

### Why this matters:

"Admins must know *why* an update failed — especially when rollback hides the crash."

Without this, the admin sees:

_"The update failed. Previous version restored."_

With this patch:

_"The update failed. Previous version restored.

LAST FATAL PHP ERROR

• [31-Oct-2025 22:41:17 UTC] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted... in /woocommerce/includes/class-wc-autoloader.php on line 58"_

---

### Patch attached:

• class-wp-automatic-updater.php — 2 small, safe changes

# diff class-wp-automatic-updater.php /usr/share/wordpress/wp-admin/includes/class-wp-automatic-updater.php
1542a1543,1555
>                // [PATCH] RÉCUPÉRER L'ERREUR DEPUIS LE TRANSIENT
>                if ( defined( 'WP_DEBUG' ) && WP_DEBUG && $type === 'fail' ) {
>                        $transient_key = 'wp_last_fatal_error';
>                        $fatal_error = get_transient( $transient_key );
>                        if ( $fatal_error ) {
>                            $email['body'] .= "\n\n=== LAST FATAL ERROR (PHP) ===\n";
>                            $email['body'] .= "• " . $fatal_error . "\n";
>                            $email['body'] .= "========================================\n";
>                            delete_transient( $transient_key );
>                        }
>                }
>                // [FIN PATCH]
>
1829a1843,1863
>
>                 if ( defined( 'WP_DEBUG' ) && WP_DEBUG ) {
>                     $fatal_error = null;
>
>                     $last_error = error_get_last();
>                     if ( $last_error && in_array( $last_error['type'], [1,2,4,256] ) ) {
>                         $fatal_error = "PHP Fatal error: {$last_error['message']} in {$last_error['file']} on line {$last_error['line']}";
>                     } elseif ( file_exists( WP_CONTENT_DIR . '/debug.log' ) ) {
>                         $lines = array_reverse( file( WP_CONTENT_DIR . '/debug.log', FILE_IGNORE_NEW_LINES ) );
>                         foreach ( $lines as $line ) {
>                             if ( strpos( $line, 'PHP Fatal error' ) !== false ) {
>                                 $fatal_error .= trim( $line );
>                                 break;
>                             }
>                         }
>                     }
>
>                     if ( $fatal_error ) {
>                         set_transient( 'wp_last_fatal_error', $fatal_error, 300 );
>                     }
>                 }

• No new dependencies
• Fully backward compatible
• Uses existing WP_DEBUG guard

---

### Ready to open PR:
I can open a PR on GitHub (wordpress/wordpress-develop) if you'd like.

Let me know if you want:

• Screenshots of the email
• Unit test draft
• Alternative using a temp file (fallback)

Happy to iterate.

Keywords: has-patch, needs-testing, administration, php-compatibility

[afragen]

A PR on GitHub would be easiest to review. Nice work.

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 in English
• Backward log reading → 0 RAM, 0 crash, even on 400MB+ debug.log

### Proof (tested on 4MB log):
`text
--- file() + array_reverse() ---
OK - Temps: 0.003s | Mémoire: +9 Mo

--- Backward reading (this patch) ---
OK - Temps: 0s | Mémoire: +0 Mo

Ready for:

Review
Unit tests (can draft if needed)
Merge

Trac ticket: https://core.trac.wordpress.org/ticket/64155
Fixes #64155
Keywords: has-patch, needs-testing, administration, php-compatibility

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See ​GitHub Pull Requests for Code Review in the Core Handbook for more details.

[tlloancy]

@afragen Thank you!

PR is live:
​https://github.com/WordPress/wordpress-develop/pull/10445

This is my first time submitting a PR to WordPress Core — I followed the GitHub PR guidelines and tested thoroughly.

Happy to make any adjustments or add unit tests if needed.

Just letting you know I’ll review and comment here.

[knutsp]

WP_CONTENT_DIR . '/debug.log' is just a default path. Suggest first checking ini_get( 'error_log' ), wich may return empty string, by

} elseif ( file_exists( ini_get( 'error_log ) ?: WP_CONTENT_DIR . '/debug.log' ) ) {

[tlloancy]

@afragen Thank you! I'm excited for the review.
@knutsp Great catch — you're absolutely right!

### Updated patch:

} else {
    $log_file = ini_get( 'error_log' ) ?: WP_CONTENT_DIR . '/debug.log';
    if ( $log_file && file_exists( $log_file ) && is_readable( $log_file ) ) {
        // ... same backward reading logic
    }
}

Checks ini_get('error_log') first (user-defined path)
Falls back to WP_CONTENT_DIR . '/debug.log'
Avoids file_exists() → no warning

Pushing it now

[afragen]

@tlloancy I’m working in the hospital a bunch for the next week so I may be a bit.

I have an old plugin that might have related code. It scrapes the error log looking for specific text and flushes the cache. Maybe it can give you some ideas. Even ideas about what not to do 😉

​https://gist.github.com/afragen/d46d3cc2c7e07d99f921560dfbb70246

[tlloancy]

@afragen No rush — hope you're doing well at the hospital. Take care!

Thanks for the gist! tail_custom() is clever with adaptive buffer.
My version uses char-by-char backward reading — stops at first fatal, scales to any log size.

PR ready for merge.

Fixes #64155
Props: @westonruter, @knutsp

[afragen]

@tlloancy as you can tell there are a number of ways to read in the error log.

@westonruter do you think there’s a benefit to adding a general function to read in the error log and scrape a section of it?

[westonruter]

@afragen I think so. It seems like something that has come up repeatedly. But I don't think it necessarily should be a prerequisite for resolving this ticket. It would be a nice bonus though!

[afragen]

Thanks @westonruter. I just figured I’d ask as I can certainly see it coming up.