How do i enable error logging in wordpress: Easy 2025

Why Your WordPress Site Needs a Detective

When how do i enable error logging in wordpress becomes your urgent search query, you’re likely in a stressful situation. Perhaps you’re staring at a broken site, a mysterious error message, or the infamous White Screen of Death. Your site might crash immediately after a routine update, a critical plugin could suddenly stop working, or a new feature might behave unpredictably. Without a log, you’re investigating blind, left to guess at the cause of the problem.

Here’s the quick answer for enabling WordPress error logging:

1. Access your wp-config.php file using an FTP client or your hosting control panel’s file manager.
2. Add these lines of code just before the line that says /* That's all, stop editing! */:
   • define( 'WP_DEBUG', true );
   • define( 'WP_DEBUG_LOG', true );
   • define( 'WP_DEBUG_DISPLAY', false );
3. Save the file and then check for a new file named debug.log in your /wp-content/ directory.

Activating error logging transforms your WordPress installation into a meticulous detective. It silently observes every process, takes detailed notes of any anomalies, and provides you with the concrete evidence needed to solve problems efficiently. Instead of randomly deactivating plugins or restoring old backups, you get exact file names, specific line numbers, and clear error descriptions. This powerful tool can turn hours of frustrating guesswork into minutes of targeted, effective fixing.

What is WordPress Debug Mode and Why Is It Crucial?

WordPress debug mode is a powerful, built-in troubleshooting state. When you enable it, you are instructing WordPress to report all PHP errors, warnings, and notices that occur across the entire platform. These aren’t always site-crashing issues; sometimes they are minor ‘hiccups’ in the code that could slow down your site, create subtle bugs, or evolve into more significant problems in the future.

When combined with error logging, this mode captures every single issue in a dedicated file, debug.log, located in your wp-content directory. This log acts as a comprehensive journal, a chronological record of everything going wrong under the hood. It is an invaluable developer tool that provides the specific, actionable details needed to stop guessing and start knowing.

Enabling error logging is indispensable for several critical reasons:

• Diagnose Problems Quickly: Error logs provide timestamps, detailed descriptions, file paths, and line numbers, allowing you to pinpoint the exact source of an error in minutes, not hours.
• Identify Faulty Plugins and Themes: The log will explicitly show which specific plugin or theme file is generating an error, making it simple to isolate the culprit without resorting to deactivating everything.
• Improve Site Performance: Even minor warnings and notices can consume server resources and add to your site’s load time. The log helps you find and fix these subtle inefficiencies to optimize your code and speed up your site.
• Proactive Maintenance: Regularly checking the error logs allows you to catch small issues, like deprecated functions or undefined variables, before they escalate into major conflicts or security vulnerabilities.
• Aid Developers: If you need to hire a professional for help, providing a detailed error log is the single most effective thing you can do. It gives the developer the exact data they need to understand and resolve the problem quickly, saving you time and money. For more insights into common WordPress problems, you can find More info about WordPress Troubleshooting.

How Do I Manually Enable Error Logging in WordPress via wp-config.php?

For direct, granular control over your site’s error handling, the manual method of editing your wp-config.php file is the most robust and reliable approach. This file is the central nervous system of your WordPress site, containing fundamental configurations like database connection details, security keys, and other core settings. By editing this file, you can give WordPress specific instructions on how to log errors behind the scenes, without ever affecting what your visitors see.

First, How to Safely Access and Edit the wp-config.php File

Safety first: Always create a full backup of your website before editing wp-config.php. This file is so critical that a single typo, a misplaced comma, or a missing semicolon can take your entire site offline. A complete backup ensures you have a quick way to restore your site if anything goes wrong.

You can access this file in two primary ways:

1. Using an FTP Client: Connect to your server using a standard FTP (File Transfer Protocol) client with the credentials provided by your hosting provider. These credentials typically include a host (your domain name or IP address), a username, a password, and a port number. Once connected, steer to your site’s root directory, which is often named public_html, www, or your site’s name. Find the wp-config.php file and download it to your computer. Before editing, it’s a wise practice to save a copy of the original file as wp-config.php.backup. Open the downloaded file with a plain text editor-never a word processor like Microsoft Word, as they can add formatting that will break the code.

2. Using a Hosting Control Panel: Log into your hosting account and open the File Manager application, which is a standard feature in most hosting control panels. Steer to your site’s root directory, locate wp-config.php, and use the built-in editor to make changes directly on the server. This method is often more straightforward for beginners as it doesn’t require separate software.

Before saving any changes, ensure the file permissions for wp-config.php are set to 644. This permission setting allows you (the owner) to read and write to the file, while preventing other users on the server from modifying it, which is a crucial security measure.

Second, Where to Add the Debug Code in wp-config.php

Placement of the debug code is critical. WordPress reads the wp-config.php file from top to bottom, and the debug settings must be added before it finishes its configuration process. Open the file and scroll down until you find the following comment line:

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

Your debug code must be placed before this line. If you place it after this line, WordPress will ignore it. It’s also common for a default wp-config.php file to already contain the line define('WP_DEBUG', false);. If you see this, it’s best to replace that single line with the complete code block below to ensure all settings are correctly applied.

Third, The Ultimate Code Snippet for Safe Debugging

This code snippet is the gold standard for enabling comprehensive error logging while keeping your site professional and secure for visitors. Copy and paste this entire block into your wp-config.php file just before the /* That's all, stop editing! */ line.

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

// Enable Debug logging to the /wp-content/debug.log file
define( 'WP_DEBUG_LOG', true );

// Disable Debug display on the front-end (important for live sites!)
define( 'WP_DEBUG_DISPLAY', false );

// Suppress errors from being displayed on the screen
@ini_set( 'display_errors', 0 );

// For developers: enable script debugging (loads un-minified JS/CSS)
// define( 'SCRIPT_DEBUG', true );

// For developers: save database queries for analysis (performance impact)
// define( 'SAVEQUERIES', true );

Here’s a quick breakdown:

• WP_DEBUG: The master switch that activates WordPress’s error detection system.
• WP_DEBUG_LOG: Tells WordPress to save all detected errors to the debug.log file.
• WP_DEBUG_DISPLAY: Set to false, this is a critical setting that prevents visitors from seeing messy and revealing error messages on the live site.
• @ini_set( 'display_errors', 0 );: This serves as an extra layer of protection to hide PHP errors from being displayed on the screen, overriding server-level settings that might otherwise show them.

The SCRIPT_DEBUG and SAVEQUERIES options are commented out by default. These are advanced tools for developers that can negatively impact site performance. Only uncomment them if you have a specific need to debug JavaScript/CSS conflicts or analyze database performance.

Once you save these changes, WordPress will immediately begin logging all errors to the /wp-content/debug.log file, giving you a powerful, behind-the-scenes record of any issues on your site.

Understanding the WordPress Debug Constants

WordPress debug constants are the specific switches and dials that give you precise control over your site’s error reporting system. Defined within your wp-config.php file, each constant serves a distinct purpose, allowing you to fine-tune your debugging setup for any situation, from a local development environment to a live production website. Understanding how do i enable error logging in wordpress properly means knowing what these constants do individually and how they work together to create a safe and effective troubleshooting environment.

WP_DEBUG: The Master Switch

WP_DEBUG is the foundation of all WordPress debugging. It’s a boolean constant (true or false) that functions as the main power switch for the entire error reporting system. By default, this is set to false to maximize performance and hide potential issues from public view. When you set define( 'WP_DEBUG', true );, you are instructing WordPress to acknowledge and process every PHP error, notice, and warning generated by the WordPress core, as well as all active themes and plugins. This is the essential first step for any troubleshooting task. For any debugging to occur, this constant must be set to true. For more details, you can consult the Official documentation on WP_DEBUG.

WPDEBUGLOG: Recording the Evidence

While WP_DEBUG turns on the error detection system, WP_DEBUG_LOG is what makes it truly useful for offline analysis. By setting define( 'WP_DEBUG_LOG', true );, you tell WordPress to save all the issues it detects to a file named debug.log inside your /wp-content directory. This creates a permanent, chronological record of everything that goes wrong. This is especially crucial for capturing errors that happen in the background, such as during AJAX requests (like form submissions) or scheduled cron jobs, which would otherwise be invisible.

WPDEBUGDISPLAY: Hiding Errors from Visitors

WP_DEBUG_DISPLAY is your guardian of user experience and site security. This constant controls whether the debug messages generated by WP_DEBUG appear directly on your web pages. For any live, public-facing site, it is absolutely essential that you set define( 'WP_DEBUG_DISPLAY', false );. This ensures that while errors are being diligently logged in the background for you to review, your visitors continue to see a clean, professional, and unbroken website. Displaying errors publicly is a major security risk, as it can reveal sensitive information about your server environment and file structure that could be exploited by malicious actors.

SCRIPT_DEBUG and SAVEQUERIES: Advanced Tools for Developers

These two constants are specialized tools for more advanced debugging scenarios, typically used by developers.

• SCRIPT_DEBUG: When you set this constant to true, WordPress will load the un-minified, development versions of its core CSS and JavaScript files. Normally, WordPress uses minified files (where all comments and extra spaces are removed) to speed up page loads. The development versions are human-readable and contain comments, making it much easier to diagnose front-end script conflicts or styling issues using your browser’s developer tools. Enable this when troubleshooting your site’s interface or functionality, but be sure to disable it afterward, as the larger files can slow down your site for regular visitors.

• SAVEQUERIES: This constant is a powerful database analysis tool. When set to true, it instructs WordPress to save every database query performed on a page load into a global array. This is invaluable for performance optimization, as it can help you identify slow, redundant, or inefficient queries generated by themes or plugins. However, SAVEQUERIES has a significant performance impact and consumes a lot of server memory, as it has to store all this data for every page view. It should only be used for temporary analysis on a staging site and never left enabled on a live production site.

The “No-Code” Way: Enabling Error Logging with a Plugin

If the idea of editing critical code files like wp-config.php sounds intimidating or you lack the necessary server access, there’s a simpler, no-code path to enabling error logging. Debugging plugins act as a friendly assistant, handling the technical work for you through a user-friendly interface directly within your WordPress dashboard.

This approach is perfect for users who prefer to stay within the familiar WordPress admin area, changing a potentially complex technical task into a few simple clicks.

How do I enable error logging in WordPress with a plugin?

The process is as straightforward as installing any other plugin, with one important caveat: you must have access to your WordPress dashboard. If your site is completely down (e.g., showing a white screen or a critical error message), you will need to use the manual method described earlier.

1. Log into your WordPress dashboard.
2. Steer to Plugins > Add New from the left-hand menu.
3. In the search bar at the top right, type a relevant term like “debug” or “error log”.
4. From the search results, choose a well-regarded plugin. Look for one with a high number of active installations, good ratings, and recent updates.
5. Click “Install Now” on your chosen plugin, and once it’s finished installing, click “Activate.”

Upon activation, most debugging plugins will automatically and safely modify your wp-config.php file with the correct constants (WP_DEBUG set to true, WP_DEBUG_LOG enabled, and WP_DEBUG_DISPLAY disabled). They handle the code placement and syntax for you. Many also add a settings page or a toggle in the admin bar for easy access to enable, disable, or view the log file directly from your dashboard, which is a significant convenience.

When to Choose a Plugin Over the Manual Method

While the manual method offers the most direct control, a plugin is an excellent choice in several common situations:

• Comfort Level: If you’re not comfortable with FTP or editing core files, a plugin provides a safe and guided experience within the WordPress dashboard.
• Access Limitations: If your hosting plan or user role prevents you from accessing files via FTP or a file manager, a plugin is your only viable option.
• Speed and Convenience: For quick or temporary troubleshooting, activating a plugin is often much faster than the download-edit-upload cycle of the manual method.
• Improved Features: Many debugging plugins go beyond basic error logging. Some offer comprehensive analysis tools for database queries, hooks and filters, API calls, and other advanced metrics, all presented in an organized, readable format.

The primary trade-off is that every active plugin adds a small amount of overhead to your site. For most users, however, the convenience, safety, and added features of a well-coded debugging plugin make it the ideal choice for getting started with error logging.

Finding, Reading, and Understanding the WordPress Error Log

Once you’ve successfully enabled error logging, your WordPress site begins its work as a diligent record-keeper, noting every issue in the debug.log file. This log is your treasure map for solving WordPress mysteries, containing precise, technical details about what went wrong, when it happened, and exactly where the problem lies in your site’s code.

How to Find and Access the debug.log File

When WP_DEBUG_LOG is set to true in your wp-config.php file, WordPress will automatically create the debug.log file in your /wp-content/ directory. You can access this file the same way you accessed wp-config.php: by using an FTP client or your hosting provider’s File Manager and navigating to that folder.

If the file isn’t there after you’ve tried to trigger an error, it could be for a few reasons:

• No Errors Occurred: It’s possible no reportable errors have happened since you enabled logging.
• Permissions Issue: The /wp-content/ folder might not have the correct write permissions. For a folder, it should typically be 755, which allows the server to write new files into it.
• Incorrect Code Placement: The debug code in wp-config.php might be placed incorrectly. Double-check that it is before the /* That's all, stop editing! */ line.
• Caching: A caching layer at the server or plugin level might be interfering. Try clearing all caches and triggering the error again.

How to Interpret the Information in debug.log

At first glance, the log file can look cryptic, but each entry follows a clear, consistent structure. Let’s break down a typical error message:

[20-Apr-2024 15:08:59 UTC] PHP Notice: Undefined index: fg2 in /home/user/public_html/wp-content/themes/mytheme/functions.php on line 166

• Timestamp: [20-Apr-2024 15:08:59 UTC] – This shows exactly when the error happened, down to the second. This is invaluable for correlating the error with a specific action you or a user took on the site.
• Error Type: PHP Notice – This indicates the severity of the issue. The most common types are:
  • Notice: A minor issue or suggestion. The script did not stop, but it indicates potential sloppiness in the code.
  • Warning: A more serious issue, but it usually doesn’t halt script execution. For example, trying to include a file that doesn’t exist.
  • Fatal Error: A critical, show-stopping issue. This type of error stops the script from running, often resulting in a blank white screen or a critical error message.
• Error Message: Undefined index: fg2 – A human-readable description of the specific problem.
• File Path: /home/user/public_html/wp-content/themes/mytheme/functions.php – This is the most valuable clue. It tells you the exact file that is causing the error. If the path includes /plugins/plugin-name/, a plugin is the culprit. If it includes /themes/theme-name/, the issue is with your theme.
• Line Number: on line 166 – This pinpoints the exact line in the specified file where the error occurred.

Common Errors and What to Do Next

Once you’ve decoded the log entry, you can take targeted action.

• Notices and Warnings: These often point to outdated or poorly written code in a plugin or theme. The best first step is to check for updates, as developers frequently fix these issues. If it’s your own custom code, you can often resolve it with simple checks, like using isset() before trying to use a variable.

• Fatal Errors: These require immediate attention. Common fatal errors include Allowed memory size exhausted or Call to undefined function. The file path will point you to the source. If it’s a plugin, you can try deactivating it by renaming its folder in /wp-content/plugins/. If it’s a theme, switch to a default WordPress theme. If your site recovers, you’ve found the problem. For memory errors, you may need to increase your PHP memory limit, often in the wp-config.php file or via your hosting control panel.

• Plugin/Theme Conflicts: Errors that mention Cannot redeclare function or class_exists often indicate a conflict where two different parts of your site are trying to define the same thing. The file path is your guide to identifying the conflicting components.

By using the log, you can move from panicked guessing to methodical, evidence-based problem-solving. For more help with critical issues, see our guide on How to fix a WordPress Critical Error.

Best Practices: Using Error Logs Safely and Effectively

Enabling error logging is a powerful diagnostic technique, but like any powerful tool, it must be handled with care to protect your site’s security, performance, and privacy. Following a few essential best practices ensures you get all the benefits of debugging without introducing new risks.

Is It Safe to Leave Error Logging Enabled on a Live Site?

No, it is not safe to leave WP_DEBUG enabled indefinitely on a live production site. While logging errors to a file (WP_DEBUG_LOG) is far safer than displaying them on screen (WP_DEBUG_DISPLAY), persistent logging on a live site still poses significant risks:

• Security Vulnerabilities: The debug.log file can expose highly sensitive information, including full server file paths, database table structures, and application logic. If an attacker were to gain access to this file (which is often in a publicly accessible directory), it would provide them with a detailed blueprint for exploiting your site.
• Performance Degradation: Continuously writing to a log file consumes server resources, specifically disk I/O. On a high-traffic site, this can contribute to slowdowns. More importantly, a forgotten log file can grow to be gigabytes in size, consuming valuable disk space and potentially causing your hosting account to be suspended.

Best Practice: Use error logging as a temporary diagnostic tool. The ideal workflow is to replicate the issue on a staging site and do your debugging there. If you must debug on a live site, enable logging, capture the error, and then disable it immediately afterward. For more on site protection, Read our WordPress Security Guide.

How to Log Custom Messages for Deeper Insights

Sometimes, the standard error messages aren’t enough. You might need to track the value of a specific variable at a certain point in the code, or simply confirm that a particular function is being executed. You can write your own custom messages to the debug log using PHP’s built-in error_log() function.

To log a simple text message, you can add this to your theme or plugin’s PHP code:

error_log( 'My custom debug message: The checkout function has started.' );

To inspect the contents of a variable, especially a complex array or object, you need to use print_r() to format it into a readable string:

$order_data = array( 'item_id' => 123, 'customer_name' => 'Jane Doe', 'status' => 'pending' );
error_log( 'Current Order Data: ' . print_r( $order_data, true ) );

The true parameter in print_r() tells it to return the output as a string instead of printing it to the screen. This is incredibly helpful for understanding how data is being processed in your code. For more details, you can read about the More on the error_log() function.

How do I disable error logging in WordPress when I’m done?

This is the critical final step in the debugging process. Once you’ve identified and fixed the issue, you must disable logging and clean up after yourself.

1. Disable the Constants (Manual Method): Access your wp-config.php file again. Change define( 'WP_DEBUG', true ); back to define( 'WP_DEBUG', false );. You can either delete the other WP_DEBUG_LOG and WP_DEBUG_DISPLAY lines or simply comment them out by adding // at the beginning of each line. This makes it easy to re-activate them later. Save the file.

2. Deactivate the Plugin (Plugin Method): Go to Plugins > Installed Plugins in your WordPress dashboard. Find the debugging plugin you installed and click “Deactivate.” Most well-built plugins will automatically revert the changes they made to wp-config.php upon deactivation.

3. Delete the Log File: This is a crucial security step. Using your FTP client or File Manager, steer to the /wp-content/ directory and delete the debug.log file. This removes the record of sensitive information and frees up disk space.

Treat error logging as a temporary diagnostic tool, like a mechanic’s code reader, to keep your site secure, fast, and healthy. For help with a comprehensive site recovery plan, see our A guide to WordPress Disaster Recovery.

Conclusion: From Error Detective to WordPress Master

Congratulations! You now know how do I enable error logging in WordPress, a skill that transforms you from someone who worries about errors into a confident, empowered troubleshooter. This is not just a technical trick; it’s a fundamental competency for effective and professional WordPress management.

You’ve learned how to bypass the frustrating guesswork and get straight to the source of a problem, whether it’s a faulty plugin, a theme conflict, or a subtle bug in custom code. Instead of the slow and painful process of deactivating plugins one by one, you can now consult the debug.log file for a precise, actionable diagnosis.

This knowledge gives you a much deeper understanding of how WordPress works under the hood. It empowers you to manage your site proactively, catching minor issues before they escalate into major headaches. Furthermore, it enables you to communicate far more effectively with developers, providing them with the exact information they need to speed up any required support, saving both time and money.

Of course, mastering error logging is just one piece of the puzzle. Total website care is a holistic practice that also involves diligent security monitoring, a robust backup strategy, continuous performance optimization, and timely updates.

If you’ve enabled error logging but find the contents of the debug.log file overwhelming, or if you’d simply rather have a dedicated expert handle these technical issues for you, our team at wpOncall is here to help. Managing the technical side of a WordPress site shouldn’t consume all of your time and energy.

We specialize in comprehensive WordPress website security and support, offering daily updates, secure backups, and unlimited support for quick issue resolution. Our expertise ensures your website stays protected, performs optimally, and runs smoothly, giving you the peace of mind to focus on what you do best: running your business. We provide Comprehensive WordPress Maintenance and Support Services to keep your digital presence secure and successful.