Using WP_DEBUG (and turning it off again)

Add two lines to wp-config.php to start logging PHP errors to a file instead of the screen, then remove them once you've found the problem. That's WP_DEBUG in a sentence: a diagnostic switch, not something to leave running on a live site.

Use it when the block editor throws an unexplained error, a plugin update breaks a page, or you're chasing a white screen with no other clues. Most day-to-day slowness or Site Health noise doesn't need it at all, see WordPress Site Health warnings and which ones matter before you reach for debug mode.

Turn it on: editing wp-config.php

Open the portal, go to Services → your hosting → File Manager, and open wp-config.php in your site's root folder. Find this line, which exists in every WordPress install:

define( 'WP_DEBUG', false );

Replace it with:

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

Each line does something specific:

• WP_DEBUG true turns on PHP error, warning, and notice reporting inside WordPress.
• WP_DEBUG_LOG true writes everything to wp-content/debug.log instead of dumping it on screen.
• WP_DEBUG_DISPLAY false plus the display_errors line stop errors from printing directly on your pages, where any visitor could see file paths and plugin names.

That combination is the one worth using almost every time: you get the log without exposing anything publicly. Skip WP_DEBUG_DISPLAY true unless you're working on a private staging copy where only you will see the page.

Reproduce the problem, then read the log

With debug logging on, do whatever triggered the issue: load the broken page, save the post, run the import, activate the plugin. WordPress appends each PHP notice, warning, and fatal error to wp-content/debug.log as it happens.

Open that file in File Manager (or download it) and read from the bottom up, since the newest entries are last. Look for:

• Fatal error lines, which name the exact file and line number that crashed. This is usually your answer.
• A plugin or theme file path repeated across multiple warnings, a strong sign that plugin is the source.
• Timestamps that line up with when you reproduced the issue, so you're not reading unrelated old entries.

If the log points at a specific plugin, deactivate it and confirm the errors stop. If you're mid-way through a bigger change, staging is the safer place to keep digging, see Using WordPress staging for the clone-and-test workflow rather than debugging on the live site.

When the block editor itself is the problem

A blank editor screen or a "this page has an error" message in Gutenberg often traces back to a plugin block registering incorrectly or a theme function conflicting with core. The same wp-config.php change surfaces it: reload the editor with debug logging on, check debug.log, and look for errors from files under wp-content/plugins/ that load around block registration.

If the log is clean but the editor is still broken, it's more likely a JavaScript console error than a PHP one. Open your browser's developer console on the same page; PHP debug logging won't catch front-end script conflicts.

Using a plugin instead of editing files

If you'd rather not touch wp-config.php directly, a debugging plugin like Query Monitor gives you the same PHP error visibility plus database query timing and hook inspection, all inside wp-admin. Install it from Plugins → Add New, activate it, and a toolbar menu appears with the details. This is a reasonable first step for a quick look, but for anything that needs a persistent log you can review after the fact, the wp-config.php method above is more reliable since it keeps recording even after you've navigated away.

Turn it back off

Debug logging is not something to leave running. It adds overhead to every request and debug.log can grow large fast, plus it sits in a predictable location that's better not left exposed. Once you've found and fixed the issue, go back into wp-config.php and set:

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

Then delete wp-content/debug.log from File Manager so old errors don't linger and confuse the next person who opens it.

If your fix involved a risky change, a theme swap, custom code, a big plugin update, do that work on a staging copy first next time. See Using WordPress staging. And before any edit that could go sideways, back up the site first on most hosting accounts so you can roll back cleanly.

If you're still stuck

If the log points at a fatal error you can't resolve, or the site is inaccessible entirely, open a ticket from Support → New ticket in the portal. A real person will look at it, and you can share your debug log or credentials securely through the ticket's password-share panel rather than pasting them in plain text.