{"id":631,"date":"2026-07-01T03:45:56","date_gmt":"2026-07-01T03:45:56","guid":{"rendered":"https:\/\/brutefort.com\/blog\/how-to-enable-wordpress-debugging\/"},"modified":"2026-07-15T13:43:36","modified_gmt":"2026-07-15T13:43:36","slug":"how-to-enable-wordpress-debugging","status":"publish","type":"post","link":"https:\/\/brutefort.com\/blog\/how-to-enable-wordpress-debugging\/","title":{"rendered":"How to Enable WordPress Debugging (The Safe Way for Live Sites)"},"content":{"rendered":"\n
\"Developer
Photo by ThisIsEngineering from Pexels<\/figcaption><\/figure>\n\n\n\n

You want to see what’s actually breaking on your WordPress site, but you’re worried that flipping on debug mode will spill PHP errors onto the screen for every visitor to see. That worry is justified \u2014 it happens to sites that get one setting wrong.<\/p>\n\n\n\n

The good news: enabling WordPress debugging safely is a five-minute job once you know which three constants to set, and in what combination. PHP fatal errors, warnings, notices, and deprecated function calls are normally suppressed entirely. Once debugging is configured correctly, they get written to a private log file instead \u2014 visible to you, invisible to visitors.<\/p>\n\n\n\n

This guide covers the complete, safe way to enable WordPress debugging on a live site, plus the one combination of settings that will expose errors publicly if you get it wrong.<\/p>\n\n\n\n

Quick Answer:<\/strong> Set WP_DEBUG<\/code> to true, WP_DEBUG_LOG<\/code> to true, and WP_DEBUG_DISPLAY<\/code> to false in wp-config.php<\/code>. That combination logs every PHP error to a file silently, without printing anything to the page. Skip the file entirely by using LogMate’s dashboard toggle instead.<\/p>\n\n\n\n

The Three Constants You Need<\/h2>\n\n\n\n

WordPress debugging is controlled by constants in wp-config.php<\/code>. You need all three of these set correctly for safe, effective error logging on a production site:<\/p>\n\n\n\n

define( 'WP_DEBUG', true );\ndefine( 'WP_DEBUG_LOG', true );\ndefine( 'WP_DEBUG_DISPLAY', false );<\/code><\/pre>\n\n\n\n
Place these above the line that reads \/* That's all, stop editing! Happy publishing. *\/<\/code><\/p>\n\n\n\n
  • WP_DEBUG<\/strong> \u2014 the master switch. It enables error reporting in PHP. Without this set to true, the other two constants do nothing.<\/li>
  • WP_DEBUG_LOG<\/strong> \u2014 writes errors to a file instead of doing anything visible. This creates (or appends to) \/wp-content\/debug.log<\/code>, which becomes your WordPress debug log.<\/li>
  • WP_DEBUG_DISPLAY<\/strong> \u2014 controls whether errors print to the page. Its default is true<\/code>. So if you only set WP_DEBUG without explicitly setting this to false, PHP errors will print to your pages for every visitor to see. Warning:<\/strong> always set this to false on a live site.<\/li><\/ul>\n\n\n\n
    For extra safety, add this line too. It suppresses error display at the PHP level in case a plugin overrides WP_DEBUG_DISPLAY:<\/p>\n\n\n\n
    @ini_set( 'display_errors', 0 );<\/code><\/pre>\n\n\n\n
    Where the WordPress Debug Log Is Written<\/h2>\n\n\n\n
    With WP_DEBUG_LOG<\/code> set to true, WordPress writes errors to \/wp-content\/debug.log<\/code>. That’s the default WordPress error log location. Some hosting environments write it elsewhere \u2014 LogMate’s System Info screen shows the exact path for both your PHP log and JS log files on your specific installation.<\/p>\n\n\n\n
    Reading the raw log file means FTP or file manager access every time something breaks. LogMate reads it for you from inside the WordPress admin instead \u2014 filterable, searchable, with occurrence counts and timestamps \u2014 so you can check your error log the same way you’d check any other dashboard screen.<\/p>\n\n\n\n
    \"LogMate<\/figure>\n\n\n\n
    \n