WordPress Debug Mode Mistakes in Production

Someone is trying to fix a white screen on a live WooCommerce site. A blog post says to turn on WP_DEBUG. Five minutes later, PHP notices are visible in the footer, a stack trace shows up in view-source, and a customer screenshots the error path and posts it on social. Debug mode is a great tool. Leaving it on in production is a classic mistake.

We clean up after this on Canadian hosting clients more often than you would think. Usually the intent was fine. The execution was not.

What WP_DEBUG actually does

In wp-config.php, WordPress reads constants that control error reporting:

• WP_DEBUG turns on PHP error reporting WordPress cares about
• WP_DEBUG_LOG writes errors to wp-content/debug.log instead of (or in addition to) the screen
• WP_DEBUG_DISPLAY controls whether errors print to HTML output
• SCRIPT_DEBUG loads unminified core JS/CSS (different problem, still not for production)

The safe production pattern when you need visibility: debug on, log on, display off. Visitors see a normal site; you read the log over SSH or SFTP.

Mistake 1: WP_DEBUG true with display still on

Many copy-paste snippets only set define('WP_DEBUG', true);. On a default PHP setup, warnings and notices can still render in the page. Deprecated notices from an old plugin look unprofessional at best. At worst they reveal file paths, table prefixes, and server layout.

Always pair debug with:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

Then reproduce the issue once, download debug.log, and turn debug off again when you are done investigating.

Mistake 2: Leaving debug on for weeks

debug.log grows without a ceiling. A noisy plugin on a busy site can write megabytes per day. Disk fills, backups balloon, and inode limits on shared hosting bite you.

Treat debug like a circuit breaker: enable for a focused window, fix or ticket the issue, disable, truncate or archive the log. On managed hosting, ask support to watch disk if you are chasing a rare intermittent bug.

Mistake 3: Debug on staging that mirrors production URLs

Teams forget staging has WP_DEBUG true while they test, then rsync wp-config.php to production by accident. Or they clone production to staging, fix the bug with debug on, and deploy only theme files while config drift stays hidden until the next full migration.

Keep staging config in git or a documented checklist. Never deploy wp-config.php from a debug-enabled environment without a deliberate diff review.

Mistake 4: Using display_errors in php.ini "temporarily"

Hosting panels sometimes expose "display PHP errors." That is global for the vhost, not just WordPress. It bypasses WP_DEBUG_DISPLAY and can leak errors from other PHP apps in the same account.

Fix at the WordPress layer or in a single pool, not by turning on display for the whole cPanel user.

Mistake 5: Logging sensitive data

Plugins and custom code that error_log() POST bodies, API keys, or user emails turn debug.log into a compliance problem. GDPR and PIPEDA both care about where personal data sits on disk.

Rotate logs, restrict file permissions (not world-readable), and scrub before sharing logs with a contractor. If a log might contain card data from a misconfigured gateway plugin, delete it and fix the plugin before PCI questions start.

Mistake 6: Relying on debug instead of proper monitoring

Debug helps developers. It does not replace uptime checks, slow query logs, or APM for production. Leaving debug on because "we might need it" usually means nobody is watching structured alerts anyway.

Use health checks, server metrics, and a staging environment that matches PHP version and extensions. Canadian teams on Edmonton or Beauharnois VPS often get lower latency to staging; use that for aggressive debugging, not the live store during peak hours.

A quick production-safe workflow

1. Reproduce on staging with full debug + log
2. If production-only: enable log-only debug in a maintenance window
3. Capture one failure, disable debug, clear display-related ini settings
4. Ship the fix via git or controlled deploy, verify with debug still off
5. Delete or archive debug.log; confirm it is not web-accessible (it should not be under a public URL)

Block direct HTTP access to debug.log with server rules if the file must live on the server briefly.

Bottom line

WordPress debug mode is for short, intentional diagnosis. Log to file, hide from visitors, turn it off when the hunt is over, and never treat a live site as your only debugger. Your customers and your disk quota will thank you.

Not sure if production is still leaking errors after a plugin update? Talk with Swift Host. We can scan config, tighten logging, and point you at staging without another public stack trace.