內容簡介
TLloancy Stack Trace 外掛可記錄 PHP 錯誤（如記憶體耗盡、解析錯誤等）、未捕獲的例外及其他外掛捕獲的例外，幫助使用者追蹤網站崩潰的原因，提供詳細的錯誤資訊以便於排除故障。
【主要功能】
• 記錄 PHP fatals 和未捕獲的例外
• 儲存崩潰時的 SQL 查詢
• 顯示記憶體使用情況和配置限制
• 提供崩潰相關的檔案和行號資訊
• 在控制台中專用的 Stack Trace 表格查看
• 支援 CSV 匯出和清除日誌功能
外掛標籤
開發者團隊
原文外掛簡介
TLloancy Stack Trace records PHP fatals (memory exhausted, parse error, and similar), uncaught exceptions, wp_die failures, and exceptions that a third-party plugin caught so the site would not white-screen.
Each row stores:
The last SQL that actually belongs to the crash (from $wpdb, or from a small adapter when a plugin talks to MySQL outside $wpdb)
Memory usage, peak, and the configured limit
File and line
The plugin, theme, or core component most likely involved
The request URL
Entries live in a dedicated table, under Tools → Stack Trace. You can export CSV or clear the log.
This is not a debug.log viewer and not a live profiler. Generic log plugins tail PHP or WordPress logs. Stack Trace records why a request died: the SQL that belongs to the crash (including plugins that never set $wpdb->last_query), memory at the limit, and exceptions another plugin caught so the site would not white-screen. Typical case: an All-in-One WP Migration export that fails with “refresh and try again” while the real cause is a 128M SELECT or a full disk.
It is for the morning after: the site crashed, nobody was watching, and you want the cause.
Plugins that bypass $wpdb
Some exporters (All-in-One WP Migration among them) run SQL on $wpdb->dbh directly. $wpdb->last_query is then empty or already overwritten (cron, Action Scheduler). Stack Trace keeps SQL in memory via adapters and, on failure, can read that plugin’s own error-log last_query field. It does not edit third-party files and does not hook their export pipeline as a stage.
Automatic update failure emails (WordPress 7.2+)
A failed automatic plugin update already includes the fatal message, file, and line. Stack Trace adds memory and last SQL from the same loopback check, with a link to the full log.
