How to Suppress Errors and Warnings in WordPress for Emergencies

Sometimes PHP errors or warnings start printing on your live WordPress site and hurt the design or confuse visitors. You can temporarily hide those on-screen messages so the public site looks normal again. That is only an emergency step. It does not repair the bug, and it does not mean the problem is gone.

Important: Hiding warnings or errors on the screen is temporary only. Display suppression does not resolve the underlying cause. Use it only as short-term mitigation on a production site, then inspect logs safely, identify the plugin, theme, or PHP code responsible, work from a backup or staging copy, fix or update that code, and verify the site. Do not treat hidden errors as safe to ignore. Turning WP_DEBUG off also does not write errors to a log file.

Temporary step: hide error messages from visitors

WordPress already includes a WP_DEBUG line in wp-config.php. Edit that existing line. Do not paste a second define( 'WP_DEBUG', ... ) — defining the same constant twice can trigger a PHP notice. Put these settings before the /* That's all, stop editing! */ comment, not after it.

1. Locate `wp-config.php`

Connect with an FTP client or your hosting file manager and open wp-config.php in the root directory of your WordPress installation.

2. Edit the existing `WP_DEBUG` line

Find the line that already looks like define( 'WP_DEBUG', true ); or define( 'WP_DEBUG', false );. Change it so debugging is off:

define( 'WP_DEBUG', false );

Use the boolean false without quotes. A quoted 'false' is a string, and PHP would treat that as true.

3. Hide remaining on-screen PHP errors if needed

Some hosts still print PHP errors even when WordPress debug mode is off. If that is happening, add the following line near your WP_DEBUG setting only if it is not already there:

@ini_set( 'display_errors', 0 );

After a careful edit, that section should look like this—not like two copies of WP_DEBUG stacked together:

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

What this does:

define( 'WP_DEBUG', false ); — Turns WordPress debug mode off. Visitors should no longer see WordPress debug output. This does not log errors for you.
@ini_set( 'display_errors', 0 ); — Tells PHP not to print errors in the page HTML. It is a display setting, not a fix.

Avoid error_reporting(0); as your main approach. It silences PHP reporting so thoroughly that it becomes harder to learn what broke.

What you must do next: diagnose and fix the real error

As soon as the public site is readable again, find the cause. A good workflow:

Make a backup before you change plugins, themes, or code.
Reproduce the problem on a staging copy or local site whenever you can, so visitors never see debug output.
On that staging copy, enable logging without showing errors on screen. Place this before /* That's all, stop editing! */, and update any existing debug lines instead of duplicating them:

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

How those lines work together:

WP_DEBUG — must be true for the other two debug constants to take effect.
WP_DEBUG_LOG — writes messages to wp-content/debug.log (or another path you set). It does nothing if WP_DEBUG is false.
WP_DEBUG_DISPLAY — set to false, plus display_errors set to 0, keeps those messages off the page so you can read them in the log instead.

Open debug.log through FTP or your host’s file manager—not by leaving it downloadable in a browser. A log file inside wp-content can expose server paths and plugin names if anyone can fetch it over HTTP. After you finish, turn debugging off again and delete or restrict the log file.

Use the log to identify the plugin, theme, or PHP file that raised the warning or error. Update or fix that code, then load the affected pages again to confirm the message is gone.

WordPress documents this debugging setup in its developer handbook.

Why you should not stop at hiding the message

Hidden errors can still break features, slow the site, or leave a security problem in place. The on-screen cleanup is only to protect visitors while you work. The real goal is a stable site with the underlying issue resolved.

Conclusion

In an emergency, you can hide WordPress and PHP error output by editing the existing WP_DEBUG line to false and, if needed, turning off display_errors—always before the “stop editing” comment, and never by defining the same constant twice. Then diagnose the cause on a backup or staging site with debug logging, fix the responsible plugin, theme, or PHP code, and verify. Hiding a warning is temporary; fixing the error is what lasts.