A bug reproduces 100% reliably – toggle a snippet off, the site works; toggle it on, it breaks – but every place that should catch an error shows nothing at all.
When Every Error-Reporting Layer Stays Silent, Trace Execution With Direct File Writes
⚡ Quick Fix (TL;DR)
The Culprit: debug.log, the server-level error log, WPCode's own fatal-error auto-deactivation, a custom register_shutdown_function fatal catcher, and a custom set_error_handler catching every warning and notice all came back completely empty, despite the bug being fully and repeatedly reproducible. Whatever was happening wasn't a standard PHP fatal, warning, or notice that any of these layers are built to see.
The Fix: Bypass every error-reporting layer entirely and trace execution by hand: drop plain, unconditional markers directly into the code with file_put_contents(), writing to a plain text file outside any logging system. Compare which markers do and don't appear across test runs to pinpoint exactly how far execution gets before something goes wrong – this was the only method all session that produced any real signal.
function zfn_debug_mark( $label ) {
file_put_contents(
WP_CONTENT_DIR . '/uploads/your-debug.log',
date('c') . " - $labeln",
FILE_APPEND
);
}
zfn_debug_mark( 'reached this point' );Tagged in :
More from the field
Bisect to an Empty Baseline Before Trusting Any Single Theory
.
Multiple plausible-sounding theories for a bug each turned out to be wrong when actually tested – time was spent building fixes…
A Security Dashboard’s Activity Log Can Lag a Full Day Behind Real Time
.
Trying to check a security tool’s activity log for an event that had just happened showed nothing at all.