Error logs help connect a failing request to PHP code, but visible errors can reveal filesystem paths, database fragments, secrets and personal data. Production diagnosis should write to a protected location while keeping browser display off.
Enable logging for a defined incident window, reproduce once and remove unnecessary logs afterward.
Check existing hosting logs first
cPanel, Plesk and managed hosts often expose PHP-FPM and web server logs already. Record their timezone, retention and which domain/PHP handler they cover.
Use the existing source when it captures the fatal; duplicating logs can consume disk and collect more sensitive data.
Do not download an entire account log when a small timestamp window is sufficient.
Back up the configuration
Copy wp-config.php to a protected backup and confirm the active WordPress document root. On multisite or relocated configurations, another file may define debugging constants.
Search for existing WP_DEBUG definitions. Defining a constant twice creates warnings and makes the effective value confusing.
Avoid editing through WordPress if the administrator itself is failing; use an authorised file manager, SFTP or SSH.
Configure WordPress logging
Place the definitions above the final “stop editing” line:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );WP_DEBUG_LOG normally writes wp-content/debug.log. It captures WordPress/PHP messages that reach this configuration, not every web server or FPM failure.
Do not use display_errors on a public production site.
Choose a protected log location
Where supported, set WP_DEBUG_LOG to an absolute path outside the public document root:
define( 'WP_DEBUG_LOG', '/protected/path/wordpress-debug.log' );The PHP user must be able to write the file, but visitors must not download it. Use a path provided by the host rather than inventing permissions.
Never make the whole directory world-writable.
Configure PHP error logging
Some fatals occur before WordPress loads. Use cPanel/Plesk or the active PHP configuration to enable log_errors and select a protected error_log.
Verify web PHP and CLI use the intended configuration files. Restart/reload PHP only through supported controls.
Do not place credentials in php.ini comments or public diagnostic pages.
Reproduce with a timestamp
Record exact time, URL/action, user state and a privacy-safe reference. Reproduce once, then read the new lines around that timestamp.
Extract:
fatal/error class
message
file and line
call stack
request correlationRedact cookies, query values, filesystem account names and personal information before sharing.
Redact without destroying diagnostic value
Keep the error class, component path relative to WordPress, line, timestamp and a generated correlation ID. Replace emails, IP addresses, tokens and request values consistently so repeated references can still be compared.
Do not use a broad regular expression that may expose secrets nested inside arrays. Review the excerpt manually before sending it to a vendor, and confirm the recipient needs the stack trace rather than only the top fatal.
Control log growth
Warnings inside loops can fill disk rapidly. Check file size during diagnosis and stop logging if it grows unexpectedly.
Use host log rotation where available and keep a bounded retention period. Never run a generic cleanup that could remove audit or application logs unrelated to the incident.
Low disk space can cause new WordPress failures, so logging must not become the outage.
Disable and verify
After the repair, set WP_DEBUG false or restore the prior configuration, remove temporary diagnostics and confirm visitors still see no errors.
Retain only the redacted incident excerpt required for documentation, then delete diagnostic files according to policy.
Recurring care should centralise protected PHP fatals and alert on new fingerprints. Safe logging produces enough evidence to repair the site without turning internal errors into public information.