Free tools Windows power users keep installed
One-click scans. No signup required.
If a WordPress page is blank, broken, or returning an error, enable debugging in wp-config.php, log the details without displaying them to visitors, reproduce the problem, and inspect the first relevant entry. Use this on a local or staging copy whenever possible, then turn it off and secure the log when the investigation is complete.
Use this safe debugging configuration
Before editing files, create a backup or switch to a staging environment. WordPress recommends debugging for local and staging installations rather than a live site.
- Open the site’s
wp-config.phpfile. - Find the line
/* That's all, stop editing! Happy blogging. */. - Add the following definitions immediately before that line. If any constant already exists, edit it instead of creating a duplicate.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Use the boolean true, not the quoted string 'true'. Likewise, 'false' is a non-empty PHP string and is treated as true, so do not write quoted values for these switches.
Reproduce the failure and read the log
With the configuration saved, repeat the action that produces the error: load the affected URL, submit the form, run the import, or trigger the background task. Then inspect wp-content/debug.log, the default log location when WP_DEBUG_LOG is true.
Recommended Free Tools
The log may contain notices from AJAX requests or WP-Cron that never appear in the page response. Start with the first fatal error or warning that coincides with the failure. Record the file path, line number, component name, PHP version message, and request that triggered it.
You can send WP_DEBUG_LOG to a different valid file path when the default location is unsuitable. An out-of-web-root path is preferable because a log inside the publicly served directory could disclose paths, queries, user data, or configuration details.
What each WordPress debugging setting does
| Setting | Effect | When to use it |
|---|---|---|
WP_DEBUG |
Enables WordPress debugging and raises PHP error reporting to E_ALL. It reports errors, warnings, and notices. |
Required for the other WordPress debug switches to have an effect; keep it off on production sites after diagnosis. |
WP_DEBUG_LOG |
Writes debug output to wp-content/debug.log when true, or to a valid custom path. |
Use when you need evidence from several requests or from background processes. |
WP_DEBUG_DISPLAY |
Controls whether debug messages are included in rendered page HTML. | Set false while logging so visitors do not see technical details. |
display_errors |
PHP’s own output switch, independent of WordPress’s logging choice. | Keep it off in the effective PHP configuration when diagnosing a public or staging-facing site. |
SCRIPT_DEBUG |
Makes WordPress load development, unminified versions of core CSS and JavaScript. | Use for frontend asset or JavaScript investigations, not as a general PHP error fix. |
SAVEQUERIES |
Stores database queries, execution times, and calling-function information. | Use briefly for database diagnosis; it adds overhead and should be disabled afterward. |
WP_ENVIRONMENT_TYPE |
Labels the installation as local, development, staging, or production. | Set an accurate environment value so tools and developers understand the site’s context. |
WP_DISABLE_FATAL_ERROR_HANDLER |
Disables WordPress’s Recovery Mode fatal-error handler. | Consider only in controlled development when Recovery Mode prevents diagnosis; do not casually disable it on a live site. |
Turn a log entry into a fix
Plugin or theme code is named
Temporarily deactivate the named plugin or switch to a default theme on staging, then repeat the failing action. If the error disappears, update the component, check its compatibility with your WordPress and PHP versions, or contact its maintainer. Deactivation is a diagnostic test, not proof that the component is permanently defective.
A PHP version, memory, or core-file problem is reported
Check the server’s PHP version and memory limit against the requirements of your WordPress version and active extensions. For an internal-server error, also investigate corrupted WordPress files and server logs. WordPress lists plugin conflicts, theme incompatibility, PHP incompatibility, memory limits, and damaged files as possible causes; the log identifies what to test, not an automatic repair.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #3
The entry is a deprecation notice
A deprecation notice identifies a function or argument that may be removed in a later release. Update or replace the component that calls it, but do not assume the notice alone caused the visible outage. Correlate its timestamp and call stack with the failed request.
The browser shows a JavaScript or styling failure
Open the browser’s developer tools and inspect the Console and Network panels. If WordPress core assets are minified, temporarily set SCRIPT_DEBUG to true in the same configuration file so stack traces and source files are easier to read. Plugin-generated JavaScript may still require that plugin’s own development build.
The log is not enough
Use a step debugger such as Xdebug in local or staging, or add an appropriate automated test. PHPUnit can reproduce application behavior without exposing diagnostics to visitors. These tools are safer and more precise than experimenting on production.
When no debug.log appears
- Confirm
WP_DEBUGandWP_DEBUG_LOGare the boolean valuetrue. - Check that the definitions are above the “That’s all, stop editing!” marker and that an earlier definition is not overriding them.
- Verify that the PHP/web process can write to the default directory or custom path. Your host may need to correct ownership or permissions.
- If a custom path is used, confirm that its parent directory exists and is writable.
- Trigger a new request after saving the file; old failures will not be added retroactively.
When visitors still see technical errors
Confirm WP_DEBUG_DISPLAY is false and that PHP’s effective display_errors setting is off. Hosting control panels, PHP-FPM pools, or server-level configuration can override a local setting, so test the actual response in a private window or staging URL. Never ask visitors to reproduce an error while details are displayed publicly.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Disable debugging and secure the evidence
- After fixing the cause, set
WP_DEBUGto false and disable temporary switches such asSCRIPT_DEBUGandSAVEQUERIES. - Remove or relocate
debug.log. WordPress warns that publicly accessible logs can expose sensitive information. - If a log must remain under the web root for a short period, restrict direct access using the controls appropriate to your web server and hosting provider.
- Clear caches and repeat the previously failing action to verify the fix with debugging disabled.
If you cannot safely edit wp-config.php
Ask your host for a staging copy, file access, and the relevant PHP/server logs, or have a WordPress developer make the change. Do not paste a fatal-error log containing passwords, API keys, session data, or full production paths into a public forum.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
