A new client called last week. The add to cart button on their WooCommerce site worked, but only sometimes. For some users it would just spin forever, no error message, nothing to go on. Their previous developer had vanished and they were losing sales. This is the kind of problem that keeps store owners up at night, and it is almost always down to silent errors that never get logged. That is exactly why solid WordPress error logging matters.
By default, WordPress is built to fail gracefully. Or, to put it another way, silently. That is good for visitors, since nobody wants a screen full of PHP warnings. For a developer it is a nightmare. You are flying blind: you know something is wrong, but not what, not where, and not when it started. So you end up trying to reproduce an intermittent bug, which is one of the fastest ways to lose your mind.
Why your WordPress error logging is probably broken
My first move was to check the browser’s developer console. It showed a generic AJAX error. Not helpful. My next thought was to fire up their staging site and turn on WP_DEBUG. The problem, of course, was that the bug wouldn’t happen on staging. It never does, does it? The issue was tied to a specific combination of live server configuration and user action. A race condition, maybe. The only way to catch it was to see the errors happening in the production environment, and you can’t just turn WP_DEBUG on for a live site. That’s developer malpractice.
So, the real fix starts with logging these errors to a private file on the server where only you can see them. Trust me on this. It’s the first thing we do on any new project. You just add a few lines to your wp-config.php file.
// Enable WP_DEBUG mode
define( 'WP_DEBUG', true );
// Enable Debug logging to the /wp-content/debug.log file
define( 'WP_DEBUG_LOG', true );
// Disable display of errors and warnings
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );That snippet tells WordPress to log every error, notice, and warning to a file called debug.log inside your /wp-content/ folder, while keeping them off the public pages of your site. Now you can see exactly what is breaking, right when it breaks.
What’s the point?
Fixing bugs without proper error logging is mostly guesswork. You poke around in the dark and hope to get lucky. A better approach is to build something that tells you when things go wrong. This config is the bare minimum, but it is a solid start. For trickier problems, especially ones that involve external services, you usually need more. A dedicated plugin that catches things like HTTP API failures or silent AJAX terminations, which Carl Alexander wrote about on his blog, is the sensible next step for any serious site.
- Stop guessing: Get real data on what’s failing.
- Fix things faster: Pinpoint the source of the error without hours of manual testing.
- Protect your users: Keep errors hidden from visitors and potential attackers.
This stuff gets complicated fast. If you are tired of debugging someone else’s mess and just want your site to work, get in touch with my team. We have probably seen it before.
