Blog

Error Log: WordPress Debug Log vs PHP Error Log for Website Troubleshooting

7 min read
12 minutes ago

Use the WordPress debug log first when the problem appears inside WordPress, and use the PHP error log when the failure may come from the server, PHP runtime, or a script that WordPress never gets to record. Both logs matter, but they answer different questions. Mixing them up can waste hours, especially when the site only shows a blank screen or a generic 500 error.

What the WordPress Debug Log Records

The WordPress debug log is created when WordPress debugging is turned on in wp-config.php. It is usually saved as wp-content/debug.log, though some hosts may store it elsewhere.

This log is focused on the WordPress application layer. It can show notices, warnings, deprecated functions, database errors, plugin conflicts, theme issues, and custom code problems. If a plugin calls a removed function or a theme loads a missing file, this log often gives the cleanest clue.

A typical configuration looks like this:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Keep WP_DEBUG_DISPLAY set to false on live sites. Displaying errors to users can expose file paths, plugin names, database details, or other sensitive data. Log the error instead. Review it privately.

What the PHP Error Log Records

The PHP error log belongs to the server environment. It records errors produced by PHP itself, not just by WordPress. This can include fatal errors, parse errors, memory exhaustion, timeout problems, permission issues, missing PHP extensions, and failed includes.

Its location depends on the hosting setup. You may find it in a hosting control panel, under logs, through cPanel, Plesk, SSH, or a custom path set in php.ini. Common names include error_log, php_error.log, or domain-specific log files.

The PHP log is especially useful when WordPress cannot load far enough to write to debug.log. That happens more often than people expect. A single syntax error in a must-use plugin can stop execution before WordPress logging begins. Honestly, it feels like the site gives you a locked door and then hides the key under a different doormat.

Main Difference: Application Errors vs Runtime Errors

The cleanest way to separate the two logs is by scope.

  • WordPress debug log: best for plugin, theme, core, shortcode, hook, REST API, and database warnings inside WordPress.
  • PHP error log: best for server-level PHP problems, fatal crashes, memory limits, bad PHP syntax, and execution failures.
  • WordPress log path: commonly wp-content/debug.log.
  • PHP log path: set by the host, PHP configuration, or server control panel.
  • Audience: WordPress log is easier for site admins and developers; PHP log often needs hosting or server access.

If a contact form fails after a plugin update, start with the WordPress debug log. If the whole site returns HTTP 500 before the admin area loads, check the PHP error log quickly.

When to Use the WordPress Debug Log

Use the WordPress debug log when the site still loads, but something behaves badly. This includes broken admin screens, failed AJAX requests, slow checkout pages, missing images generated by plugins, or errors after a theme update.

It is also helpful during safe testing. Developers can reproduce an issue, refresh the page, then check the latest entries. The timestamps show what happened during that request. That simple timing can cut guesswork by half.

Good use cases include:

  1. Plugin conflicts: Two plugins may call the same function or load incompatible libraries.
  2. Theme errors: A template file may call an undefined function.
  3. Deprecated code: An old plugin may still work but trigger warnings under a newer PHP version.
  4. Database issues: Failed queries may appear when custom tables are missing or damaged.
  5. REST API problems: Errors may appear during block editor saves or integration calls.

It drives me crazy that some plugins write vague messages like “something went wrong” in the interface, while the log shows the exact missing class name. Always read the log before reinstalling half the site.

When to Use the PHP Error Log

Use the PHP error log when the failure is severe. Blank page. HTTP 500. White screen after editing a file. Admin locked out. Cron jobs failing with no WordPress message. These are strong signs that PHP itself may have stopped execution.

The PHP log may reveal entries such as:

  • PHP Fatal error: Allowed memory size exhausted
  • PHP Parse error: syntax error
  • PHP Warning: failed to open stream
  • PHP Fatal error: Uncaught Error: Class not found
  • PHP Notice: Undefined index

Some of these also appear in the WordPress debug log. Some do not. The difference depends on when the error happens and whether WordPress was active enough to record it.

How to Read Both Logs Without Getting Lost

Start with time. Match the timestamp of the user report with the timestamp in the log. If a customer says checkout failed at 14:07, do not scan yesterday’s entries first. Look at that minute.

Then look for severity. A fatal error usually matters more than a notice. A notice may be harmless, or it may point to poor code that later breaks under stricter settings. Treat repeated warnings seriously if they appear during the same action that users report.

Use this simple order:

  1. Reproduce the issue once, if safe.
  2. Check the WordPress debug log for plugin or theme messages.
  3. Check the PHP error log for fatal errors or memory issues.
  4. Compare timestamps with the failed request.
  5. Disable or update the suspect component on staging first, when possible.
  6. Clear caches and test again.

Security and Cleanup

Error logs can expose private information. They may contain file paths, usernames, query strings, plugin names, IP addresses, API response data, or fragments of customer input. Treat them as sensitive files.

Never leave a public debug.log exposed. Some poorly configured servers allow direct browser access to files under wp-content. Block access with server rules, move logs outside the public web root if possible, or use host-level logging tools.

After troubleshooting, turn WordPress debugging off unless you have a reason to keep private logging active:

define('WP_DEBUG', false);

Also rotate or delete old logs. Large log files can grow fast. A busy WooCommerce site can produce hundreds of megabytes of warnings in a few days if one plugin loops through bad calls.

Practical Troubleshooting Example

Picture a membership site where users cannot reset passwords. The password reset page loads, but the email never arrives. The WordPress debug log shows a mail plugin warning tied to an expired API key. That is a WordPress-level issue, so the fix is inside the plugin settings.

Now picture a different case. The site shows a blank page after a PHP version upgrade. The WordPress debug log is empty. The PHP error log shows a fatal error from an old ionCube loader. WordPress did not get far enough to record anything. The server log gives the real answer.

Best Practice

Do not choose one log and ignore the other. Use them together. The WordPress debug log explains what happens inside WordPress. The PHP error log explains what happens in the PHP runtime and server context.

For most website troubleshooting, start narrow and then widen the search. Check wp-content/debug.log for WordPress-specific entries. If the symptom is fatal, intermittent, or blank, check the PHP error log right away. That two-log habit gives faster answers, fewer guesses, and cleaner fixes.