Something broke. Where's the error?
A plugin update broke the checkout page. A theme change caused a white screen on mobile. A client reports "something looks wrong" but the page loads fine in your browser.
PHP errors are happening on the frontend, but WordPress doesn't show them to you. To find them, you need to SSH into the server, edit wp-config.php, add WP_DEBUG constants, reload the page, read a raw log file, then remember to undo it all when you're done.
That's a lot of steps for "show me what's broken."
What most people do instead
Each approach has a catch that makes it harder than it should be.
A better way: toggle, browse, read
Open the navigator. Type debug mode. Hit enter. Debug capture is now on.
Browse your frontend pages. Come back and run the command again. Every PHP error, warning, notice, and deprecated call is listed inside the navigator, color-coded by severity, newest first.
Shown in advanced mode, where commands start with tp. In easy mode you type the same command without the tp prefix.
Your visitors never know. Errors are captured silently server-side. Nothing is printed to the page. No file paths exposed. No performance impact.
How it works
Three-step debugging loop, entirely from the admin.
debug mode to start. PHP error handlers register on every frontend page load.| Detail | Value |
|---|---|
| Command name | debug mode |
| Enable | debug mode (toggles on) |
| Disable | tp debug mode -off |
| Clear log | tp debug mode -clear |
| Log capacity | 50 entries, 1-hour auto-expiry |
| Captures | Fatal, Error, Warning, Notice, Deprecated |
| Scope | Frontend page loads only (not admin or AJAX) |
| Can be used in |
Real example
A client updates their theme on a WooCommerce store. Everything looks fine on the homepage, but individual product pages take 4 seconds longer to load than before.
You open the navigator and run debug mode. Then you open a product page in another tab. Back in the admin, you run the command again.
Result: 3 errors captured. Two are DEPRECATED calls to get_page_by_title() in the theme's breadcrumb function. One is a WARNING from a missing product attribute the theme expects. The deprecated function triggers a fallback query on every product page. That's the 4-second penalty.
You fix the breadcrumb function, clear the log with tp debug mode -clear, reload the product page, and check again. Zero errors. Page load is back to normal. Total debugging time: 6 minutes.
Goes further with TrueCommander
Quick debugging from the admin. Combine it with other commands for a full diagnostic workflow.
Frequently asked questions
WP_DEBUG to true in wp-config.php over FTP, which is fiddly and easy to leave on by accident. tp debug mode toggles error capturing without touching any file and shows the results inside the navigator.debug.log file over FTP.tp debug mode -off to stop capturing and tp debug mode -clear to wipe the collected entries. It is best used while you diagnose an issue, then switched off.