Enable WordPress debug mode and read the debug log

When WordPress shows a white screen, a critical error or a broken feature, the real cause is usually a PHP error that is hidden from visitors. Debug mode records those errors so you can see exactly which file and line failed.

Before you start

• Access to cPanel → Files → File Manager.
• A downloaded copy of wp-config.php in case you make a typo.

Turn on debug logging

1. Edit wp-config.php and find the line define( 'WP_DEBUG', false );.
2. Replace it with the block below, keeping it above the "stop editing" comment.
3. Save the file and reproduce the problem by loading the broken page.

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

This writes errors to wp-content/debug.log without showing them to visitors. Showing errors on screen exposes file paths and is not recommended on a live site.

Read the log

Open wp-content/debug.log in File Manager. Each line has a time, an error level and a file path, for example:

PHP Fatal error: Uncaught Error: Call to undefined function foo() in /home/user/public_html/wp-content/plugins/example-plugin/inc/init.php:42

• Fatal error: stops the page; this is the line you need. The folder after plugins/ or themes/ names the culprit.
• Warning and Notice: usually harmless, but they can hint at outdated code.
• Deprecated: code that will break in a future PHP or WordPress version.

Keep the log private

By default debug.log is reachable from the web. Point it to a folder outside public_html instead:

define( 'WP_DEBUG_LOG', '/home/USERNAME/logs/wp-debug.log' );

Create the logs folder first and replace USERNAME with your cPanel username.

Check the server error log too

Some errors happen before WordPress loads. Look in cPanel → Metrics → Errors for the latest Apache/LiteSpeed errors, and check for an error_log file in the site folder, which PHP creates automatically.

Act on what you find

• A plugin is named: deactivate it by renaming its folder, then update or replace it.
• A theme is named: switch to a default theme by renaming the active theme's folder.
• Allowed memory size exhausted: raise the PHP memory limit.
• Maximum execution time exceeded: raise max_execution_time or optimise the task.

Turn debugging off again

Set WP_DEBUG back to false and delete debug.log when you are done. A log left running can grow to hundreds of megabytes and count against your disk space.

Other debugging tools

• SCRIPT_DEBUG: define( 'SCRIPT_DEBUG', true ); loads unminified core CSS and JavaScript, useful when a dashboard screen breaks.
• SAVEQUERIES: stores every database query for the request. Only use it briefly, because it slows the site.
• Query Monitor plugin: shows PHP errors, slow queries, hooks and HTTP calls in the admin bar for logged-in admins. Deactivate it when you are finished.
• Site Health: Tools → Site Health → Info lists the PHP version, limits, active plugins and constants, which is handy to paste into a support ticket.

Troubleshooting

• No debug.log appears: no error happened since you enabled logging, the wp-content folder is not writable, or the constant was placed after the wp-settings.php line.
• The log fills with the same notice: an outdated plugin calls deprecated code on every page. Update or replace it; notices alone do not break a site.
• Still a white page with logging on: the error happens before WordPress starts. Check the error_log file and cPanel → Metrics → Errors.

Next steps

• Fix the WordPress white screen
• Find a plugin conflict
• Fix allowed memory size exhausted