WordPress Debug should log the actual error, not show the server details to the visitor. On production, the error display should be off and the logging interval should be short and targeted. Not all PHP fatals reach debug.log either; Pre-bootstrap errors should be found in the PHP-FPM or host log.
Quick answer: Take a backup from wp-config.php, define the constants before the break line and only once, turn logging on and display off. Then reproduce the problem once, note the timestamp, and return the additional settings after gathering evidence.
Adjustable setting for logging without public display
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );These lines should be before the stop editing statement in wp-config.php. If the constant is already defined, change the same value; Repeated definition makes the result ambiguous. wp-config contains sensitive information and should not be placed in a public ticket or open repository.
What exactly does each setting do?
| Setting | Usage | Note |
|---|---|---|
WP_DEBUG | Enable Mode debug | produce more warning |
WP_DEBUG_LOG | log to specified file or path | log may be sensitive |
WP_DEBUG_DISPLAY | show error in response | stay off on production |
SCRIPT_DEBUG | core development asset | not usually needed for PHP error |
SAVEQUERIES collects queries and has overhead; It is only suitable for specific and short analysis in a controlled environment.
How to record a usable sample?
- Specify the timezone of the server and application.
- Do not delete the old log; Have a time marker or rotation.
- Execute exactly the same URL and broken entry once.
- Read the lines around the timestamp, not just the last line.
- After logging, turn off extra debug and protect the file.
If debug.log is not created
Maybe the content path is custom, PHP doesn't have write permission, constant definition is not effective, or error before WordPress logger to occur Check PHP-FPM, Apache/Nginx or Panel logs. Do not use chmod 777 to remove access; The minimum ownership and permission must be consistent with the PHP execution user.
Error logging is different from error display
Enable display_errors In PHP, it can reveal file path, class name and internal data in HTML or JSON. Logging and display are two separate decisions. On the public site the appropriate message of the user is preserved and the details are logged in the protected destination.
In Docker or some backend
the container filesystem may be temporary and the debug.log is destroyed with recreate or written to another node. Check volume, stdout/stderr, log driver and container id. request ID helps to track a request between proxy, PHP and application.
What is the difference between debug in staging and production?
In staging, you can have more detailed logging, but the environment must be separate from the public internet, search engine and real services. Production requires data retention, rotation and minimization. If the error only occurs in production, list the version, config, data, cache, cron, and traffic differences; Blindly transferring all data to staging has both privacy risks and may change the cause.
How to make sure the settings are effective?
The presence of lines in the file is not enough. The application may use a different wp-config, override the fixed environment, or the request may reach a different node. Match the root path of the site with the deployment and control the logging destination timestamp after a real request. Don't intentionally cause a PHP error on production to "test"; Reproduce the same reported event.
Volume management and log maintenance
A warning inside a loop can quickly grow a file and take up disk space. Monitor the file size and free space, modify the repetition source and define the appropriate rotation. Constantly deleting the file without fixing the cause is not capacity control. In the container environment, check the log driver and host level retention limits separately.
What does debug not prove?
Enabled debug alone does not find the cause, and the absence of messages does not prove complete health. Frontend error, network timeout, process kill and cache response may not be seen in debug.log. The result should be reconciled with the HTTP status, web server log, browser behavior and, if necessary, the server resource status. Also, a warning related to a plugin does not necessarily mean that the same plugin is to blame for the current failure; The time, severity and route of the request are decisive.
What should we delete before sharing?
- cookie, nonce, token and authentication header
- password and DSN database
- email, phone and order information
- API key and full webhook payload
- Paths including system username
after detection
WP_DEBUG and turn off additional logging according to project policy, but do not remove standard PHP logging and production monitoring. Record the cause, versions, timestamp and modification. If you have a fatal message, the Critical Error Guide explains how to proceed.
When is professional help appropriate?
If no log is generated, the error is intermittent, or information is propagated between PHP-FPM and the web server, WordPress Technical Troubleshooting Servicecan check the whole chain.
FAQ
Does WP_DEBUG slow down the site?
Depending on the volume of warning and I/O it can make overhead; Production use should be short and targeted.
Should debug.log be publicly downloadable?
No. This file may contain internal data and must be protected with an appropriate location or rule.
Does turning off WP_DEBUG stop all logging?
No. PHP-FPM and the web server have independent policies and their operational logging should be maintained.