debugging in wordpress

WordPress Debugging Demystified: Find and Fix Errors Fast

Debugging in WordPress: Fix Errors 2025

Why WordPress Debugging is Essential for Every Website Owner

Debugging in wordpress is the process of identifying and fixing errors that can break your website’s functionality, cause the dreaded white screen of death, or create mysterious issues that frustrate visitors and hurt your business. When a plugin conflict, theme issue, or coding error occurs, you need to see what’s happening behind the scenes to fix it fast.

Here’s how to enable WordPress debugging in 3 simple steps:

  1. Access your wp-config.php file via FTP or your host’s file manager.
  2. Add debugging constants before the /* That's all, stop editing! */ line.
  3. Check the debug.log file in your wp-content folder for error details.

Think of debugging as a diagnostic tool for your website. Without it, you’re guessing what went wrong. With debugging enabled, you can pinpoint the exact source of the problem. For small business owners, this is critical. Every minute your site is malfunctioning costs you potential customers and revenue. Understanding debugging helps you move from panic to problem-solving, providing clear information about what needs fixing.

I’m Kevin Gallagher, and with over 15 years of experience and more than 2,500 WordPress websites built, I’ve helped hundreds of business owners through wpOncall master debugging in wordpress to keep their sites running smoothly and avoid costly downtime.

Infographic showing the WordPress debugging workflow: Step 1 - Enable debug mode in wp-config.php by setting WP_DEBUG to true, WP_DEBUG_LOG to true, and WP_DEBUG_DISPLAY to false. Step 2 - Reproduce the error on your website. Step 3 - Check the debug.log file in wp-content folder for error details including file path and line number. Step 4 - Fix the identified issue. Step 5 - Disable debug mode by setting constants back to false. - debugging in wordpress infographic

Related content about debugging in wordpress:

Understanding the Core WordPress Debugging Constants

At the heart of debugging in wordpress are several PHP constants you can define in your wp-config.php file. Think of these as switches that control how WordPress reports errors. They give you granular control over whether you see errors on the screen, log them to a file, or access deeper performance metrics. For complete technical details, refer to the official Debugging in WordPress Documentation.

Here’s a comparison of the main debugging constants:

Constant Purpose Recommended Setting (Staging/Local) Recommended Setting (Live Site)
WP_DEBUG The master switch for debugging. Enables debug mode throughout WordPress. true false
WP_DEBUG_LOG Logs all errors, notices, and warnings to a debug.log file in wp-content. true true (for monitoring)
WP_DEBUG_DISPLAY Controls whether debug messages are shown on the screen. true (conditionally) false
SCRIPT_DEBUG Forces WordPress to use development versions of core CSS and JavaScript files (un-minified). true false
SAVEQUERIES Saves database queries to an array ($wpdb->queries) for analysis. Has performance implications. true false

WP_DEBUG: The Master Switch

WP_DEBUG is the main toggle for the entire debugging system. By default, it’s set to false to hide internal issues from visitors. When you set it to true, WordPress starts reporting every PHP error, notice, and warning it encounters. This constant must be enabled for the other debugging constants to work.

define( 'WP_DEBUG', true );

Warning: Never leave WP_DEBUG set to true on a live website, as it can expose sensitive information.

WPDEBUGLOG: Recording Errors to a File

WPDEBUGLOG works with WP_DEBUG to record all errors to a debug.log file inside your /wp-content/ directory. This is invaluable for catching errors that happen in the background, such as during cron jobs or AJAX requests. It creates a historical record of issues, complete with timestamps.

define( 'WP_DEBUG_LOG', true );

This is the recommended way to monitor for issues on a live site, provided WP_DEBUG_DISPLAY is turned off. For more details, see our WordPress Error Logs Guide.

WPDEBUGDISPLAY: Showing Errors on Screen

WPDEBUGDISPLAY controls whether error messages are printed directly onto your website’s pages. While useful for immediate feedback during development, this is a major security risk on a live site. It creates a poor user experience and exposes file paths and code structure. Always set this to false on a production server.

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

SCRIPT_DEBUG: For CSS and JavaScript Issues

SCRIPT_DEBUG is a tool for frontend troubleshooting. WordPress normally uses minified (compressed) versions of its core CSS and JavaScript files to improve speed. These files are nearly impossible for humans to read. Setting SCRIPT_DEBUG to true forces WordPress to load the full, un-minified versions, making it much easier to debug script conflicts or styling issues.

define( 'SCRIPT_DEBUG', true );

SAVEQUERIES: Analyzing Database Performance

SAVEQUERIES is a powerful but resource-intensive tool for diagnosing slow websites. When enabled, it saves every database query performed on a page load into an array. This allows you to analyze which queries are slow or inefficient. However, it has a significant performance impact and should never be left enabled on a live site. It’s an essential tool when following our Fix WordPress Errors Guide for performance tuning.

define( 'SAVEQUERIES', true );

How to Manually Enable WordPress Debugging (The Developer’s Way)

Manually enabling debugging in wordpress gives you the most control and is the standard method used by developers. Before you begin, a critical rule: always test changes on a staging environment or after making a complete backup. Modifying core files like wp-config.php on a live site without precautions is risky.

You will need to access your website’s files using an FTP client (like FileZilla) or the File Manager in your hosting control panel (cPanel). If you’re new to the WordPress file system, the Beginner’s guide to WordPress file structure is a helpful resource.

FTP client showing WordPress file structure - debugging in wordpress

Step 1: Access and Edit Your wp-config.php File

Connect to your server via FTP or log in to your hosting panel and open the File Manager. Steer to your website’s root directory, which is often named public_html or after your domain. You’ll know you’re in the right place when you see the wp-admin, wp-content, and wp-includes folders. The wp-config.php file is located in this same directory. Right-click the file and select “Edit” or “View/Edit”.

In the wp-config.php file, scroll down until you find the line:

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

You must add your debugging code before this line. Here is the recommended snippet for safe and effective debugging:

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

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

// Disable display of errors and warnings on front-end
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

// Use dev versions of core JS and CSS files (only when needed)
// define( 'SCRIPT_DEBUG', true );

wp-config.php file with debug code snippet highlighted - debugging in wordpress

After adding the code, save the file. Now, visit your website and perform the action that was causing the issue. This will trigger the error and ensure it gets logged.

Step 3: Find and Interpret the debug.log File

Steer to the /wp-content/ folder. If an error has occurred, you will now see a file named debug.log. If the file isn’t there, it may mean no errors have been triggered yet. Try to reproduce the issue again.

Open the debug.log file. Each entry will have a timestamp and describe the error type (e.g., Notice, Warning, Fatal Error), what went wrong, the full file path, and the exact line number causing the problem. This information is the key to fixing the issue. For more help with this step, see our guide on How to Enable Error Logging in WordPress.

  • Notices: Minor issues that don’t break the site but indicate improper code.
  • Warnings: More serious issues that don’t stop script execution but are problematic.
  • Fatal Errors: Critical errors that stop the script and often cause a white screen.

Step 4: Safely Disable Debug Mode After Troubleshooting

Once you have resolved the issue, it is crucial to disable debugging mode on your live site. Leaving it enabled poses a security risk and can affect performance. Edit your wp-config.php file again and change the WP_DEBUG constant back to false.

define( 'WP_DEBUG', false );

For good practice, you can also set WP_DEBUG_LOG to false and delete the debug.log file from your wp-content directory. This ensures no sensitive information is left on the server.

Using Plugins for Easier Debugging in WordPress

If editing core files feels daunting, debugging in wordpress plugins offer a user-friendly alternative. These tools provide a visual interface within your WordPress dashboard, translating technical errors into organized, understandable information. They often add a menu to the admin bar, giving you real-time insights without needing FTP access.

Query Monitor plugin interface showing database queries - debugging in wordpress

While many options exist, a few plugins are industry standards for debugging in wordpress:

  • Query Monitor: The most comprehensive debugging plugin. It provides detailed information on database queries, PHP errors, hooks and actions, enqueued scripts and styles, HTTP API calls, and much more. It’s an all-in-one tool for developers and site administrators.
  • Debug Bar: A classic and reliable tool that adds a debug menu to the admin bar. When WP_DEBUG is enabled, it cleanly displays PHP warnings and notices, query information, and cache details.
  • Log Deprecated Notices: This plugin focuses on a specific problem: identifying the use of outdated WordPress functions in your themes and plugins. This helps you proactively update your code to prevent it from breaking in future WordPress versions.

How to Use Query Monitor for Advanced Debugging in WordPress

Query Monitor is the most powerful of these plugins. Once installed and activated, it adds a new menu to your admin bar showing key metrics like page generation time and database query count. Clicking this menu opens a detailed panel at the bottom of the page.

This panel gives you access to a wealth of information organized into tabs:

  • Queries: Lists all database queries for the current page load, highlighting slow or duplicate queries. This is essential for diagnosing performance bottlenecks.
  • PHP Errors: Displays any PHP errors, warnings, and notices in a clean, readable format, often with a stack trace to show you where the error originated.
  • Hooks & Actions: Shows all the WordPress hooks that fired on the page, which is useful for debugging plugin conflicts or custom code.
  • Scripts & Styles: Lists all CSS and JavaScript files loaded on the page, along with their dependencies and sizes. This helps identify frontend issues.
  • HTTP API Calls: Monitors any requests your site makes to external services, showing response times and potential errors. This is useful for debugging issues with third-party integrations.
  • Environment: Provides a snapshot of your server setup, including PHP and WordPress versions, which is helpful for troubleshooting compatibility issues.

Query Monitor turns debugging in wordpress from a code-heavy task into a visual, data-driven process, allowing you to quickly identify and resolve issues.

Advanced Debugging Techniques and Tools

When standard debugging isn’t enough to solve a complex problem, you may need more advanced techniques. These methods provide deeper insight into your code’s execution and frontend behavior. For more troubleshooting resources, explore our WordPress Troubleshooting Category.

Using error_log() for Custom Messages

Sometimes you need to know what’s happening inside a function as it runs. PHP’s built-in error_log() function lets you send custom messages to your debug.log file. This is perfect for tracking variable values or confirming that a specific block of code is being executed.

To log a simple message or variable:

// Check if a function is being called
error_log( 'My custom function was successfully called.' );

// Log the value of a variable
$user_id = get_current_user_id();
error_log( 'The current user ID is: ' . $user_id );

When working with arrays or objects, you must use print_r() to log their contents in a readable format:

// Log the contents of an array or object
$post_object = get_post( 123 );
error_log( 'Post Object Contents: ' . print_r( $post_object, true ) );

The true parameter tells print_r() to return the data as a string rather than printing it to the screen. For guidance on adding code like this safely, see this article on how to add custom code in WordPress.

How to Use Browser Developer Tools for Frontend Debugging in WordPress

Many WordPress issues are related to the frontend (CSS, JavaScript, images). Every modern web browser includes developer tools that are essential for debugging in wordpress frontend problems. Access them by right-clicking on a page and selecting “Inspect” or pressing F12 (Cmd+Option+I on Mac).

Browser's developer tools console showing a JavaScript error - debugging in wordpress

  • Console: This is the first place to look for JavaScript errors. If a slider, form, or button isn’t working, the Console will likely show red error messages pointing to the problematic script.
  • Elements: This tab lets you inspect and edit the page’s HTML and CSS in real-time. It’s perfect for troubleshooting layout problems and testing CSS changes on the fly.
  • Network: This tab shows every file the browser loads for the page. You can identify slow-loading assets, broken images (404 errors), and failed AJAX requests.

Identifying Common WordPress Errors

As you debug, you’ll encounter recurring error types. Understanding them helps you diagnose issues faster.

  • Fatal Errors: These are critical errors that stop script execution, often resulting in a blank white screen. Your debug log will point to the exact file and line number. Our guide on How to Fix Critical Errors in WordPress can help.
  • Syntax Errors: Caused by typos in your code, like a missing semicolon or bracket. These also break your site but are usually easy to fix once located.
  • PHP Notices and Warnings: These are less severe. Notices indicate potential issues, while warnings flag problems that don’t necessarily stop the page from loading. They are signs of poor code quality that should be addressed.
  • Database Connection Errors: This error means WordPress can’t connect to its database. It’s usually caused by incorrect credentials in wp-config.php or a server issue.

Frequently Asked Questions about WordPress Debugging

We’ve helped hundreds of website owners through wpOncall, and a few questions about debugging in wordpress come up frequently. Here are clear answers to the most common concerns.

What are the risks of leaving WP_DEBUG enabled on a live site?

Leaving WP_DEBUG enabled on a live site is a significant risk for three main reasons:

  1. Security Vulnerabilities: If WP_DEBUG_DISPLAY is also enabled, error messages can be shown to visitors. These messages often contain sensitive information like server file paths and code structure, which can give attackers a roadmap to exploit your site.
  2. Poor User Experience: Displaying cryptic PHP errors on your site looks unprofessional, can break the page layout, and will drive potential customers away.
  3. Performance Impact: While minor on small sites, the constant process of checking for and logging errors consumes server resources, which can slow down a busy website.

Solution: Always set WP_DEBUG to false on a live site when you are finished troubleshooting. For ongoing monitoring, you can leave WP_DEBUG_LOG set to true as long as WP_DEBUG_DISPLAY is false.

Why isn’t my debug.log file being created?

If the debug.log file isn’t appearing in your wp-content directory, it’s usually due to one of these common issues:

  • WP_DEBUG is not enabled: The WP_DEBUG_LOG constant only works if WP_DEBUG is also set to true.
  • Incorrect Placement: The debug constants must be placed in wp-config.php before the line that reads /* That's all, stop editing! Happy blogging. */.
  • File Permissions: WordPress needs permission to write to the wp-content directory. If the folder permissions are too restrictive (they should typically be 755), the server will prevent the file from being created.
  • No Errors to Log: The file is only created when the first error, warning, or notice occurs. If your site is running perfectly, the log file won’t be generated.

Can a plugin interfere with the debugging process?

Yes, this is a common source of confusion. Some plugins or themes use their own custom error handling functions (set_error_handler()) to manage errors. This can intercept the errors before WordPress’s default debugging system can log them, making it seem like your debugging setup isn’t working.

To diagnose this, follow these steps:

  1. Deactivate all plugins.
  2. Switch to a default WordPress theme (like Twenty Twenty-Four).
  3. Try to trigger the error again.

If your debug.log file now works as expected, you’ve confirmed an interference. Reactivate your theme and plugins one by one, testing after each activation, until the problem returns. The last item you activated is the culprit. You can then check for an update, find an alternative, or contact the developer for support.

Conclusion

Mastering debugging in wordpress transforms you from a worried website owner into a confident problem-solver. Mysterious crashes and frustrating errors become clear, actionable issues that you have the power to diagnose and fix. We’ve covered the essential tools for the job, from the core debugging constants to user-friendly plugins.

You’ve learned how to enable debugging manually by editing wp-config.php for full control, and how to use plugins like Query Monitor for a more visual approach. We’ve also touched on advanced techniques like custom logging and using browser developer tools to handle even the trickiest issues. Most importantly, we’ve stressed the golden rule: always debug on a staging site and disable debug mode on your live site when you’re done to protect your security and user experience.

At wpOncall, we’ve seen how this knowledge empowers business owners. After building over 2,500 WordPress sites, we know that understanding debugging is the key to maintaining a healthy, high-performing website. It’s the difference between a quick fix and costly downtime.

However, we also know that your time is valuable. If you’d rather focus on your business than on technical troubleshooting, our team is here to help. We provide the expert support and security monitoring your website needs to thrive. For total peace of mind, consider our Comprehensive WordPress Maintenance plans. We’ll keep your site secure, updated, and running flawlessly, so you never have to worry about an error message again.