Safe WordPress Error Logging in Production

Why You Should Not Display Errors on a Live Site

The `WP_DEBUG_DISPLAY` setting controls whether PHP and WordPress messages are shown in the page response. If it is enabled, the site may display warnings, theme or plugin file paths, function names, SQL fragments, and other internal data.

Even a message that appears harmless can reveal a library version, directory structure, or the name of a vulnerable component. In addition to creating a security risk, technical output can break the page layout and end up in caches, screenshots, or external service logs.

On production, debug mode should not be used as a permanent monitoring method. Enable it for a limited time, reproduce the problem, analyze the entries, and restore the secure configuration.

• Do not use `WP_DEBUG_DISPLAY` with a value of `true` on a public site.
• Do not send users complete stack traces or SQL error messages.
• Do not leave detailed logging enabled without controlling the file's size and access.

How to Enable Logging Without Displaying Errors

Open `wp-config.php` and add the settings before the line `That's all, stop editing! Happy publishing.` or its localized equivalent. Do not create duplicate constants: if they already exist in the file, update the existing values instead of adding new lines below them.

A basic configuration for temporary troubleshooting looks like this:

• `WP_DEBUG` enables WordPress debugging mode.
• `WP_DEBUG_LOG` writes messages to a log file.
• `WP_DEBUG_DISPLAY` prevents diagnostic messages from being displayed in the browser.
• `display_errors` is additionally disabled at the PHP level for the current request.

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

Where the Log Is Written

With the default configuration, WordPress writes diagnostic messages to `wp-content/debug.log`. In some configurations, `WP_DEBUG_LOG` can be replaced with a path to another file, such as a separate directory for service logs. That path must be compatible with filesystem permissions and your hosting configuration.

Before changing the path, check the documentation for your WordPress version and environment. An incorrect path or missing write permissions will prevent messages from appearing in the expected file.

How to Check the Problem and Read debug.log

After saving `wp-config.php`, reproduce the error in the same way a user encounters it: open the relevant page, submit a form, or perform the problematic action in the admin area. Then check whether a new entry has appeared in the log file.

To view the latest lines on a Linux server, you can use:

• Look for the event time, file name, line number, and component that caused the message.
• Compare entries from before and after a specific action to distinguish the current error from older messages.
• Check not only `Fatal error`, but also `Warning`, `Notice`, `Deprecated`, and database error messages.
• If the file is not being updated, check the actual path, write permissions, and the logs for PHP-FPM, the web server, or the hosting platform.

tail -f wp-content/debug.log

What to Analyze in an Entry

Pay attention to the component mentioned in the path: a plugin, theme, custom code, or WordPress core. The line number helps locate the error, but it does not always indicate the true cause. The problem may result from incompatible PHP or plugin versions, or from invalid data.

Do not edit code without a backup, and do not make untested production changes based on a single log line. Whenever possible, reproduce the problem in a staging environment first.

How to Protect the Error Log File

The `wp-content/debug.log` file is often located in a directory accessible through the web server. If the server serves it at a direct URL, anyone may be able to download the technical records. Logs may sometimes contain email addresses, user IDs, SQL fragments, tokens, or request data.

The best option is to store the production log outside the public web root if your configuration supports it. If the file must remain in `wp-content`, restrict access at the web-server level and verify the protection with a separate request in a private browser window.

• For Apache, use a rule that denies access to the specific file or directory, in accordance with the server configuration.
• For Nginx, add a separate `location` rule that denies access to `debug.log`.
• Do not rely only on hiding the URL or using a nonstandard file name.
• Filesystem permissions should allow the web-server user to write to the file without making it accessible to all system users.
• After configuring protection, test access both over HTTP and directly through SSH.

Log Rotation, Size, and Privacy

Errors may recur on every request, so `debug.log` can grow quickly. A large file consumes disk space and makes it harder to find the relevant event. On a production server, configure rotation at the operating-system or hosting-control-panel level.

Treat the log as confidential technical data during analysis. Do not publish it in full in chats or tickets. Before sending it to a developer, remove passwords, tokens, cookies, email addresses, IP addresses, and other personal data.

If plugin or theme code manually writes data with `error_log()`, make sure it does not include passwords, API keys, complete request bodies, or payment information. WordPress logging does not make such data safe automatically.

• Set a maximum file size and the number of archived copies.
• Restrict access to archives in the same way as access to the current log.
• Delete old copies in accordance with your internal data-retention policy.
• Monitor available disk space after enabling diagnostics.

How to Disable Debug Mode After Troubleshooting

Once the cause of the error has been identified and verified, restore the production configuration. This usually means disabling all four settings or removing the temporary lines from `wp-config.php`.

• Make sure `WP_DEBUG` is set to `false`.
• Disable `WP_DEBUG_LOG` if persistent logging is not required by your monitoring system.
• Keep `WP_DEBUG_DISPLAY` disabled in production.
• Check the site in a browser and review the PHP or web-server logs after making the change.
• Securely delete or archive the old `debug.log` if it is no longer needed.

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

If the Error Is Needed for Long-Term Monitoring

For ongoing monitoring, it is better to use PHP or web-server logs, or a specialized monitoring system with access control, filtering, and rotation. Do not leave detailed WordPress debug mode enabled simply because the site occasionally has errors.

If your production environment supports environment variables or a separate staging configuration, keep diagnostic settings outside the repository and make sure they are not accidentally transferred to the live site.