[[INSTRUCTION: ]]

# How to Enable WP_DEBUG in WordPress: A 3-Step Guide for Beginners

When your WordPress site encounters an issue—whether it’s the infamous White Screen of Death (WSoD), a malfunctioning plugin, or a strange formatting error—the software often fails silently, leaving you with no information to diagnose the problem. For developers and advanced users, this is a minor setback; for beginners, it can feel like hitting a brick wall.
Fortunately, WordPress includes a powerful, built-in system to break this silence: WP_DEBUG.
WP_DEBUG is not a solution in itself, but rather a diagnostic tool that forces WordPress to display and log detailed error messages, warnings, and notices that are normally hidden. Enabling this feature is the single most important step in troubleshooting, as it often reveals the exact line of code, plugin, or file that is causing the error.
This guide is designed for beginners. It will walk you through the entire process of enabling WP_DEBUG using three simple steps, ensuring you can turn on the verbose error reporting you need, and just as importantly, turn it off safely when you’re done.
Understanding WP_DEBUG and Its Importance
What is WP_DEBUG?
WP_DEBUG is a PHP constant—a predefined variable whose value remains the same throughout the execution of a script. It’s defined within your site’s main configuration file, wp-config.php.
By default, this constant is set to false, meaning error reporting is suppressed. When you change it to true, WordPress begins operating in “debug mode.”
WP_DEBUG’s primary functions are:

Displaying Errors: Showing warnings, notices, and errors directly on your screen as they occur.
Logging Errors: Saving a record of these messages to a file, which is crucial for issues that don’t appear every time or happen in the backend.

Why You Must Use It
Without debugging enabled, troubleshooting is often a process of trial-and-error: deactivating plugins, switching themes, or guessing. With WP_DEBUG enabled, you receive a clear, actionable message.
Example of an Undebugged Error (WSoD): You see a blank white screen. Example of a Debugged Error: You see: “Fatal error: Cannot redeclare function in /wp-content/plugins/bad-plugin/bad-file.php on line 42.” This instantly tells you the problem is within the “bad-plugin” on a specific line of code.
Prerequisites: Gaining File Access
Since WP_DEBUG is defined in the wp-config.php file, and this file is outside your WordPress dashboard, you need direct access to your server’s file system.
You Will Need:

FTP Client: A program like FileZilla or Cyberduck. This is the recommended, safest way to transfer and edit files.
FTP Credentials: Your hostname, username, and password, which you can get from your hosting provider’s control panel (cPanel, Plesk, etc.).
A Text Editor: A simple, plain text editor (like Notepad on Windows, TextEdit on Mac, or a code editor like VS Code) to edit the file. Do not use word processing software (like Microsoft Word), as it can introduce hidden formatting that will break your site.
A Backup: Always a good idea before editing core files!

The 3-Step Guide to Enabling WP_DEBUG

Step 1: Access and Edit wp-config.php
The wp-config.php file is located in the root directory of your WordPress installation.

Connect via FTP: Use your client and credentials to connect to your web server.
Navigate to the Root: Locate the main folder of your website (usually public_html, www, or a folder named after your domain).
Locate the File: Find the file named wp-config.php.
Download and Open: Download the file to your computer and open it with your plain text editor.

Once the file is open, scroll down to the section near the bottom that says:

PHP


/* That's all, stop editing! Happy blogging. */




Step 2: Define the WP_DEBUG Constant
You need to insert the primary debug constant just above the “stop editing” line.
Insert the following line:

PHP


define( 'WP_DEBUG', true );




This single line activates the debug mode. However, for a proper diagnostic session, it’s highly recommended to also include the two constants below it to control where and how the output is handled.
The complete block of recommended code to insert should look like this:

PHP


// Enable Debugging
define( 'WP_DEBUG', true );
// Enable Debug Logging to the /wp-content/debug.log file
define( 'WP_DEBUG_LOG', true );
// Disable the display of errors on the screen
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );




Explanation of the Extra Constants:

define( 'WP_DEBUG_LOG', true );: This is critical. It tells WordPress to save all error messages to a file called debug.log within your wp-content folder. This is useful for capturing transient errors or errors triggered by cron jobs or background processes.
define( 'WP_DEBUG_DISPLAY', false );: This is a best practice. It tells WordPress to log the errors but not to display them on the live website screen. Displaying raw code errors can ruin the user experience and, more importantly, poses a security risk by revealing file paths and server information. The combined use of WP_DEBUG: true and WP_DEBUG_DISPLAY: false is the recommended setup for live sites.

Step 3: Save, Upload, and Check the Logs

Save the File: Save the wp-config.php file on your local machine.
Upload the File: Upload the modified wp-config.php file back to your server’s root directory via FTP, overwriting the original file.
Trigger the Error: Now, visit the page on your website that was causing the issue. This action forces WordPress to execute the faulty code and record the error.
Check the Log: Navigate to the wp-content folder on your server via FTP. You should now find a new file named debug.log. Download and open this file.

The debug.log file will contain a chronological list of all errors, warnings, and notices that occurred. Look for the lines labeled Fatal error—these are the ones that typically crash your site and will point directly to the plugin, theme, or file responsible.
Post-Troubleshooting: Disabling Debug Mode
This is the most crucial step. Never leave WP_DEBUG enabled on a live production website.
As mentioned, displaying or even just logging detailed internal server information poses a significant security risk and can negatively affect site performance.

Once you have identified and fixed the error (e.g., deleted the faulty plugin, corrected the line of code), you must disable debugging:

Re-Edit wp-config.php: Access the file via FTP again.
Change the Constant: Change the primary constant back to false.

PHP


define( 'WP_DEBUG', false );





Optional Cleanup: You can either delete the entire block of debugging code you inserted, or simply change all the associated constants to false and comment them out (//).
Delete the Log File: Delete the debug.log file from your wp-content folder to clean up unnecessary logs and prevent public access to internal information.

Conclusion
Enabling WP_DEBUG transforms the often-frustrating experience of WordPress troubleshooting into a logical, data-driven process. By inserting just a few lines of code into your wp-config.php file, you unlock verbose error reporting that instantly points you to the source of the problem, whether it’s an incompatible plugin, a memory limit issue, or a theme error. For beginners, mastering this simple, 3-step technique is foundational, providing the clarity needed to fix common site errors quickly and safely, provided you always remember to disable it when your work is done.