Reading PHP Error Logs on DirectAdmin to Debug Web Apps

When your website shows a "500 Internal Server Error", a blank white screen, or behaves erratically, the PHP Error Log is the first place to check. This file records every PHP error that occurs in your code, allowing you to pinpoint the root cause precisely without guessing. This guide explains how to enable and read PHP Error Logs on DirectAdmin Hosting.

What is a PHP Error Log?

A PHP Error Log is a plain text file where PHP writes details of every error that occurs during script execution. Errors fall into several severity levels:

• Fatal Error — Critical errors that stop script execution immediately (e.g., calling an undefined function)
• Warning — Non-fatal issues that signal problems to fix
• Notice — Informational hints that code could be improved
• Parse Error — Syntax errors like missing semicolons or unclosed brackets
• Deprecated — Functions scheduled for removal in future PHP versions

Enabling PHP Error Logging on DirectAdmin

Method 1 — Edit php.ini via DirectAdmin

1. Go to DirectAdmin → Advanced Features → PHP Configuration
2. Set these values:

error_reporting = E_ALL
log_errors = On
error_log = /home/username/public_html/php_errors.log
display_errors = Off

Always set display_errors = Off on production servers to prevent error messages from being visible to website visitors.

Method 2 — Use .htaccess

If you don't have direct php.ini access, use .htaccess:

php_flag log_errors on
php_value error_log /home/username/public_html/php_errors.log
php_flag display_errors off
php_value error_reporting 32767

Method 3 — WordPress wp-config.php

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

WordPress will write errors to wp-content/debug.log automatically.

How to Read the PHP Error Log

After enabling error logging, access the log file in several ways:

Via DirectAdmin File Manager

1. Open File Manager
2. Find php_errors.log or debug.log
3. Right-click and select View or Edit

Via SSH / Shell

# View last 50 lines
tail -n 50 /home/username/public_html/php_errors.log

# Follow log in real-time
tail -f /home/username/public_html/php_errors.log

# Search for Fatal Errors only
grep "Fatal error" /home/username/public_html/php_errors.log

Interpreting Error Messages

Example error message and what each part means:

[16-May-2026 10:23:45 UTC] PHP Fatal error: Uncaught Error: Call to undefined function get_header() in /home/user/public_html/wp-content/themes/mytheme/index.php:5

• Timestamp — When the error occurred
• Error type — Fatal error / Warning / Notice
• Description — Call to undefined function get_header()
• File and line number — index.php on line 5

Common PHP Errors and Solutions

• Call to undefined function — Missing include or plugin that defines the function
• Class not found — Autoloader not loaded or incorrect namespace
• Memory exhausted — Increase memory_limit in php.ini or wp-config.php
• Maximum execution time exceeded — Slow query or infinite loop; increase max_execution_time
• Permission denied — Incorrect file permissions; files should be 644, folders 755

Key php.ini Settings for Debugging

Beyond error logging, several php.ini values significantly affect how errors are captured and how much headroom PHP has to run your scripts. The table below shows recommended values for development versus production environments — these two contexts should always differ.

On DirectAdmin, navigate to Advanced Features → PHP Configuration to adjust these values without direct server access.

Debugging WordPress with Query Monitor

For WordPress sites, the Query Monitor plugin is the most comprehensive real-time debugging tool available — and it reads much more than just PHP errors. Once activated, a summary bar appears in the WordPress admin area on every page load with instant access to deeper panels.

• Database Queries — Lists every SQL query executed for the current page with its execution time, helping you identify slow or redundant queries
• PHP Errors — Surfaces Warnings, Notices, and Deprecated calls in context, complete with a stack trace
• Hooks & Actions — Shows which hooks fired and which plugin or theme triggered them — invaluable for diagnosing plugin conflicts
• HTTP API Calls — Reveals outbound HTTP requests WordPress made during the page load, surfacing timeouts or failed third-party API calls
• Memory usage — Displays per-page RAM consumption to identify memory-hungry plugins

Install it from the WordPress plugin directory by searching "Query Monitor". Deactivate it before pushing to a public-facing production environment, as the debug bar is visible to any logged-in administrator.

Protecting the PHP Error Log from Public Access

Log files stored inside public_html are potentially accessible to anyone who knows the URL. A log containing file paths, database names, or stack traces is a useful map for an attacker. Three layers of protection will eliminate the risk.

Option 1 — Move the log outside public_html (best)

Point error_log to a directory above the web root:

error_log = /home/username/logs/php_errors.log

Files above public_html cannot be accessed via HTTP, making this the most effective approach.

Option 2 — Block via .htaccess

If the log must stay inside public_html, deny browser access in .htaccess:

<FilesMatch "\.(log|txt)$">
    Order Allow,Deny
    Deny from all
</FilesMatch>

Option 3 — Use an unpredictable filename

Rename the log from php_errors.log to something like err_a8f3b2c.log. This makes automated discovery harder but should never replace the options above.

Comparing PHP Debugging Tools on Shared Hosting

Different debugging tools suit different workflows. The table below helps you choose the right approach for your situation without over-engineering your setup.