# Enable WP_DEBUG and read the error log
Source: https://docs.webgee.com/en/hosting/wordpress/how-to-view-enable-and-view-errors-on-a-wordpress-installation-wp-debug







`WP_DEBUG` makes WordPress record the errors it would otherwise hide. It is the
first step in diagnosing a white screen, a fatal error, or a plugin that does
not behave. Applies to all WordPress sites.

Errors are written to a log file, not shown on the page — which is what makes
this safe to use on a live site.

## Edit wp-config.php [#edit-wp-configphp]

`wp-config.php` is in your site's root folder, normally `public_html`. Open it
with cPanel's **File Manager** or an FTP client.

<img alt="Opening wp-config.php for editing" src="__img0" />

Find the existing line:

```php
define( 'WP_DEBUG', false );
```

Replace it with:

```php
// Enable WP_DEBUG mode
define( 'WP_DEBUG', true );

// Log errors to wp-content/debug.log
define( 'WP_DEBUG_LOG', true );

// Do not display errors to visitors
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
```

<img alt="The debug constants added to wp-config.php" src="__img1" />

<Callout type="warn">
  These lines must go **above** the comment `/* That's all, stop editing! */`.
  Anything after it is ignored, and the most common reason debugging appears not
  to work is that the constants were added at the bottom of the file.
</Callout>

If `WP_DEBUG` is not defined anywhere in the file, add the block above that
comment.

### WP\_DEBUG\_DISPLAY must stay false [#wp_debug_display-must-stay-false]

`WP_DEBUG_DISPLAY` set to `true` prints errors into the page HTML for every
visitor, including file paths and, on some errors, database detail. Leave it
`false` and read the log.

### SCRIPT\_DEBUG [#script_debug]

Some guides add `define( 'SCRIPT_DEBUG', true );`. That makes WordPress load
unminified core JavaScript and CSS, which is only useful if you are debugging
core files themselves. Leave it out otherwise — it slows every page load.

## Reproduce the problem [#reproduce-the-problem]

Save the file, then go back to the site and do whatever caused the error.
Nothing is logged until the error happens again.

## Read the log [#read-the-log]

Open `wp-content/debug.log`.

Each entry gives the error, the file path and the line number. Work from the
**oldest** entry, not the newest — a single fatal error usually cascades into
several follow-on warnings, and the first one names the real cause.

A path under `wp-content/plugins/some-plugin/` points at that plugin. Deactivate
it and see whether the error stops.

## Turn it off afterwards [#turn-it-off-afterwards]

Set `WP_DEBUG` back to `false` and &#x2A;*delete `wp-content/debug.log`**.

<Callout type="warn">
  `debug.log` sits inside the web root and can be readable over the internet at
  `example.com/wp-content/debug.log`. It contains file paths and can contain
  query fragments. Delete it when you have finished, and do not leave debugging
  enabled on a live site indefinitely — the file grows without limit.
</Callout>

## Related [#related]

* [Fix a site stuck in maintenance mode](/en/hosting/wordpress/wordpress-my-site-is-showing-a-maintenance-page-how-do-i-disable-it)
* [Reset WordPress permalinks](/en/hosting/wordpress/how-to-reset-your-wordpress-permalinks)