WordPress Debugging: Enabling WP_DEBUG and Reading Error Logs

WordPress Debugging: Enabling WP_DEBUG and Reading Error Logs

Debug with evidence – not guesswork

WordPress debugging turns vague “it broke” reports into readable PHP notices, fatals, and plugin traces – if you keep display off on production and logs private.

When a form fails, a checkout stalls, or a white screen appears after an update, logs beat random plugin deactivation roulette. Pair this guide with White Screen of Death fixes when the admin UI is gone.

Verified: July 2026 – procedures tested against WordPress 7.0.2 on PHP 8.3-8.5 in staging. Always keep a rollback path: WordPress Repair if you are stuck mid-incident.

Production safety box

  • Set WP_DEBUG_DISPLAY to false on live sites – never show errors to visitors.
  • Keep debug.log outside the public web root when possible, or block HTTP access to it.
  • Redact passwords, tokens, and personal data before sharing logs with anyone.

Helper snippet: Disable PHP error display. Memory ceiling: Increase PHP memory limit.

Different logs answer different questions

Do not look only in wp-content/debug.log – the failure may live in PHP-FPM, WooCommerce, the browser, or an external API.

  • WordPress debug.log – PHP notices/warnings/fatals from WP, themes, plugins when WP_DEBUG_LOG is on.
  • PHP-FPM / web server logs – segfaults, upstream timeouts, 502/504, permission issues.
  • WooCommerce logs – WooCommerce → Status → Logs for payment gateways, webhooks, and fatal-errors files.
  • Browser DevTools – JS errors, failed REST calls, CORS, blocked third parties.
  • External services – SMTP, CDN, payment, CRM webhooks – check their dashboards when WP looks “fine.”

Enabling WP_DEBUG safely

Use staging first; on production prefer logging without display.

In wp-config.php (above “That’s all, stop editing!”):

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

Optional on staging only:

define('SCRIPT_DEBUG', true);
define('SAVEQUERIES', true); // heavy - disable after profiling

Reproduce the bug once, copy the relevant log slice, then turn debug constants back off on production if you do not need ongoing logging.

Recovery Mode, Site Health, Query Monitor, REST, cron

Modern WordPress gives you safer isolation tools than FTP-only workflow.

  • Recovery Mode – email link after a fatal error; disable the offender without a full outage.
  • Site Health – PHP modules, REST availability, scheduled events, HTTPS issues.
  • Query Monitor (staging) – slow queries, HTTP requests, hooks, capability checks.
  • REST errors – failing block editor, headless frontends, and app passwords show up as 4xx/5xx in Network.
  • Failing crons – stuck wp-cron jobs explain delayed emails, subscriptions, and sitemap pings.

After a bad update: restore from backup, or roll the plugin/theme version, then re-test on PHP 8.3+ before trying again.

Reading common messages

  • Fatal error: Allowed memory size exhausted – raise memory carefully; find the leak/plugin looping.
  • Call to undefined function / class – missing plugin dependency or wrong load order.
  • Deprecated on PHP 8.x – fix or replace before it becomes a fatal in a later PHP.
  • Maximum execution time exceeded – heavy import, remote HTTP, or runaway loop.

Checklist

  1. Backup or snapshot first.
  2. Enable log-only debug on a controlled environment.
  3. Reproduce once; capture WP + server + browser evidence.
  4. Isolate plugin/theme via Recovery Mode or staging toggles.
  5. Redact secrets; fix; re-test; disable noisy logging on production.

Related on WP-Dude

Loading (streaming)