TLloancy Stack Trace

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.