Debug errors in PHP applications or files

A blank screen or a 500 error shows that the request did not finish as expected, but does not by itself identify the layer or component that failed. The source may be the application, PHP, a .htaccess directive, the web server or a resource limit.

Reproduce the exact URL or operation and note the time. Start with the narrowest source that may contain that event:

1. If you know the application, check its log or debug mode first, keeping on-screen error output disabled. For WordPress, use Debug errors in WordPress.
2. If the application log does not contain the event, or it is a standalone PHP file, check the PHP log for the effective version. If it is not active, temporarily enable log_errors from cPanel.
3. If the request does not appear in PHP, .htaccess was modified or the error occurs before the application runs, check the site's or web server's error log.

A log not containing the request does not prove that the application has overridden the configuration. First check the effective PHP version, the scope of the configuration, the destination and permissions of error_log, and whether the request reached that layer.

Only attribute the failure to a component when the log or a controlled reproduction links it to the specific message. Until then, any explanation is a hypothesis.

Close the diagnosis

Keep the first error and its stack trace, the change that fixed it and the result of repeating the same operation. A line in a library may be where invalid data was detected, not where it was created; avoid changing that file without following the trace.

Remove temporary debugging, confirm that details are not shown to visitors and keep logs only for as long as necessary. When asking for help, provide a minimal example with dummy data and the PHP and application versions, without attaching full configurations that contain passwords.