Something’s not right. You email your developer, or our support, or post in the forum, and the first reply is the same: “Can you send your debug log?”
You take a breath. You don’t remember where the WP debug log lives, or whether you even have one turned on. You search “how to enable WP_DEBUG”, find a Stack Exchange answer from 2014, gingerly edit wp-config.php, hope you didn’t break the site, refresh the page, and then can’t find the log file. So you install a debug plugin. Now there’s another plugin to manage, and the log it shows you is everything from every plugin running on the site. You scroll, copy what you think is the relevant bit, paste it into the ticket, and hope.
The Tracksies debug log skips that whole process. Every Tracksies plugin you have installed gets its own toggle on the Settings > Debug page. Flip the one you’re troubleshooting on. Reproduce the bug. Hit Copy for Support. Paste into the ticket. Flip the toggle back off when you’re done. The log file is deleted automatically.
Per-plugin scoping
Each installed Tracksie has its own toggle: HQ, Trustie (Free or Pro), Packsie, Squizzie, Pipesie, Perkie. They write to separate log files in wp-content/uploads/tracksies-logs/, so when support asks “what’s Packsie doing during a return?” you don’t have to scroll through Trustie’s review-rendering noise to find it.
Toggle on the one (or two) you’re troubleshooting. The others stay quiet. No site-wide debug noise.
What gets captured
Each entry has a timestamp, a level (debug / info / warning / error), and the message. Levels colour-coded in the viewer so you can scan for red errors first. The system records what each plugin chooses to log: PIN events, AJAX calls, sync operations, integration handshakes, error conditions, and the small “what step are we at” breadcrumbs that tell a developer what was actually happening.
Designed to be read, not just logged
A standard PHP error log is cryptic by default. Stack traces, file paths, opaque function names, the kind of output that says “send this to your developer” because nobody else can parse it. Tracksies’ log entries are written to be read by a human, not just dumped for a developer to grep later.
What that looks like in practice:
- Operational events read like a story. “Return RMA-123 status changed: received → inspected.” “Refund of $24.99 requested for 1x Blue Mug by Jo — pending manager approval.” “Customer profile viewed by Priya — customer ID 4711.” You can scan a log and understand the sequence of what happened without needing a translator.
- Error events stay technical where they need to be. When something genuinely breaks, the log captures the file, line, and exception detail your developer (or our support team) needs to actually fix it. Cryptic-on-purpose, not by accident.
- Levels split scannable from urgent. Info entries are the breadcrumbs (“X happened”). Warning entries are “this looked off but we recovered”. Error entries are “this didn’t work and someone needs to know”. The viewer colour-codes them so the red lines jump out.
The result: a shop owner can usually figure out enough to describe the problem in their own words (“the refund happened twice in a row about an hour after I left”) without needing to understand the code. Support / your developer reads the same log and gets the technical detail to act. Same file, two audiences, no translation step.
Copy for Support
Two buttons on the live log viewer:
- Copy All — raw log content, just what’s in the file.
- Copy for Support — formatted ticket-ready dump with the log content plus your site’s basic system info (WordPress version, PHP version, active plugins, theme, the bits a developer needs to see at a glance). One click, pasted straight into a support ticket or your dev’s email.
That second button is the one that turns “send me your debug log” from a 30-minute exercise into a 30-second one.
Live viewer
While debug is on for a plugin, the viewer at Settings > Debug updates as the log grows. Reproduce the bug, scroll back through the entries that just landed, see what the system was doing at each step. Useful when you’re talking to a developer in real time and they want to see what changes when you click a specific button.
Automatic cleanup
Two safeguards keep the logs from growing forever:
- Per-file rotation. Each plugin’s log is capped at 5 MB. When it hits that, the file rotates so it never balloons your hosting space.
- Automatic delete on disable. When you toggle a plugin’s debug off, its log file is deleted. No “I forgot to clean up”, no orphan files sitting in your uploads directory weeks later. Off means gone.
There’s also a manual Clear log button in the viewer if you want to start fresh mid-session (for example, you’ve reproduced the bug once and want a clean log for the second try).
Why we built it this way
Debug logs are the moment shop owners feel furthest from their site. The standard answer is “edit wp-config and install a plugin”, which means asking a non-developer to change a file the WordPress UI deliberately doesn’t let them edit. We didn’t want that to be the path between a question and an answer. One toggle per plugin, one copy button, automatic cleanup — the same friction a developer expects, none of the friction a shop owner shouldn’t have to deal with.
When you don’t need it, it’s off. When you do, it’s one click to start, one click to share, one click to stop. That’s it.