WordPress PHP error log reader
Which plugin is filling your error log? A debug.log is thousands of lines of the same few warnings, with the one fatal error that matters somewhere in the middle. Paste it here: fatals first, repeats collapsed into one line with a count, and every entry traced to the plugin or theme it came from.
Where the log is
WordPress writes one only when it is told to; your host usually keeps one either way.
WordPress’s debug.log
With WP_DEBUG and WP_DEBUG_LOG set to true in wp-config.php, WordPress writes PHP errors to wp-content/debug.log. Download it with your host’s file manager or SFTP and open it above. Keep WP_DEBUG_DISPLAY false on a live store, so the errors go to the file and not into your pages.
The host’s PHP error log
Most hosting panels have a “logs” or “error log” page, and many write an error_log or php_errors.log file beside the site. An nginx error log with PHP message: lines works too.
How to read the result
The count tells you what is noisy. The level tells you what is broken.
- Fatal means the request stopped: a page that did not load, an order that did not go through, a scheduled action that failed. One fatal on checkout matters more than a thousand notices.
- Database errors are queries that failed. A deadlock now and then is retried; the same error over and over usually means a missing table or a plugin’s broken query.
- Warning means PHP carried on with something missing, such as an array key or a file. Often harmless, sometimes the start of a wrong total or an empty field.
- Notice and Deprecated are housekeeping for the plugin’s developer: code that will stop working on a future PHP or WordPress version. Send them the line; there is rarely anything for you to fix.
- An entry raised inside WordPress core is traced through its stack trace to the first plugin or theme that called it. When there is no trace, it stays with core; that does not mean core is at fault.
A payment failure often leaves only a few new warnings, not a fatal. If orders stopped after an update, work through what to check when WooCommerce payments are failing; if a form stopped and the log is clean, the failure may be in the browser, as in a broken WordPress quote form after a plugin update.
A log you read once is a log you read too late
The fatal that matters happened at 2 a.m., and you find it next week while looking for something else. Operanse reads it for you.
Monitor records PHP errors as the store raises them, with messages redacted, alongside its orders, payments and renewals. Insight also reads the PHP error log on every cron run: counts by level and three redacted samples of each, with file paths reduced to file names. Watch, free for one store, does not read errors, but it mails you when the store can no longer take an order, when scheduled actions pile up or fail, and when renewals start failing.
The plugin only reads. It never sends the log itself, and never changes anything on your store.
Questions
Is the log uploaded anywhere?
No. Error logs carry customer emails, order numbers and query text, so the reader runs entirely in your browser: a file you open is read from your disk by the browser, not uploaded, and nothing is stored or put in the page address. Our page-view counter records only that the reader was used, never anything from the log.
My log is huge. Will it cope?
A file over 20 MB is read from its end, the newest 20 MB, which is usually what you want. For a bigger window, cut the part you need with a text editor or tail -n 200000 debug.log and paste that.
Why does an error count as the same when the numbers in it differ?
Two lines are collapsed when the level, the source and the message match. For a memory error the allocation size is ignored, and for a database error the query is ignored and the error and its caller are kept, because the query differs for every order.
Which entries have no plugin or theme?
Lines that name no file under wp-content, such as most database errors and messages plugins write with error_log(). The message usually says enough to tell whose they are.
Should I leave WP_DEBUG on?
On a live store, only with WP_DEBUG_DISPLAY false, and not for longer than you need: the log grows without limit and is often readable from the web at /wp-content/debug.log. Point WP_DEBUG_LOG at a path outside the web root if you keep it on.