=== TLloancy Stack Trace ===
Contributors: tlloancy
Tags: debug, error log, fatal error, memory, crash
Requires at least: 6.0
Tested up to: 7.1
Requires PHP: 7.4
Stable tag: 1.0.0
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Logs fatal errors, memory crashes, and exceptions swallowed by other plugins, with SQL, memory, file/line, and the plugin involved.

== Description ==

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.

== Installation ==

1. Upload the `tlloancy-stack-trace` folder to `/wp-content/plugins/`.
2. Activate the plugin from the Plugins screen.
3. Open the log under Tools → Stack Trace.

== Frequently Asked Questions ==

= Does this slow the site down? =

On a normal request the cost is a shutdown callback that returns immediately unless PHP reports a fatal. A row is written only when something is recorded. Adapters add work only for the target plugin's AJAX (for example an All-in-One export hop): a header check on success, disk I/O only on failure.

= How many entries are kept? =

300 by default. Older rows are pruned when you open the admin page. Override the limit with `TLLST_MAX_ENTRIES` in wp-config.php.

= Does the plugin change other plugins' files? =

No. It does not reorder `active_plugins` and it does not patch files on disk.

= Why is the last SQL not always from $wpdb? =

If the crash is inside a known custom MySQL client, `$wpdb->last_query` is often unrelated. The adapter's in-memory SQL (or that plugin's error log) is used instead.

== Changelog ==

= 1.0.0 =
* Initial release.
* Fatals, swallowed exceptions, and memory crashes with SQL, memory, file/line.
* Adapter for All-in-One WP Migration (observe only).
* WordPress 7.2 automatic update failure emails include memory and last SQL from the loopback check, per failed plugin.
