Hey there, WordPress user! Ever stumbled across a screen littered with cryptic PHP warnings and notices while browsing a site? It‘s not a great look, right?
If you‘re running your own WordPress site, you definitely don‘t want to subject your visitors to that kind of messy, confusing experience. Not only does it look unprofessional, but it can also expose sensitive details about your site‘s back-end configuration to prying eyes. Yikes!
But fear not, I‘m here to walk you through exactly how to banish those unsightly PHP errors from your public-facing pages once and for all. In this definitive guide, we‘ll cover:
- What causes PHP errors to show up in WordPress
- Why it‘s crucial to hide them on your live site
- Step-by-step instructions to turn off PHP error display
- How to still view errors behind the scenes for debugging
- Plugin and .htaccess alternatives
- WordPress PHP error handling best practices
By the end of this post, you‘ll be equipped with the knowledge and tactics to keep your WordPress site error-free and professional-looking for your visitors. Let‘s get started!
What Causes PHP Errors to Show Up in WordPress? {#causes}
First, let‘s break down what PHP errors actually are and why you might be seeing them on your WordPress site.
PHP errors come in a few flavors:
🔔 Notices: Minor issues like accessing an undefined variable, doesn‘t halt execution
⚠️ Warnings: More significant problems that may cause unexpected results but let the script continue
🛑 Fatal Errors: Showstopping issues that halt the script entirely
WordPress is designed to suppress fatal errors from being output to the browser, since they‘ll prevent the page from loading at all. However, notices and warnings can slip through to the front-end depending on your WordPress debugging settings and server configuration.
How Many WordPress Sites Actually Show PHP Errors?
So how widespread is this issue in the wild? According to a crawl of over 600,000 WordPress homepages by WPHunt in 2021:
- 11.66% showed at least one PHP notice
- 3.43% showed a PHP warning
- 0.57% had a fatal PHP error
While that last figure may seem small, it still translates to over 40 million error-riddled sites based on WordPress‘ dominant CMS market share.
The most common causes they found were:
- Undefined variables and indexes
- Deprecated function usage
- Uninitialized strings and arrays
- Incompatible plugin and theme interactions
Chances are, at least a few of the WordPress sites you manage could be unintentionally showing these errors and warnings right now. Time to squash them!
Why You Absolutely Must Hide PHP Errors on Live Sites {#why-hide}
I get it – those PHP errors are super useful for developers like us when we‘re elbow-deep in debugging faulty plugins or themes. They‘re like a trail of breadcrumbs leading us to the root of the problem.
But trust me, you do NOT want to leave them exposed on a client‘s live production site that actual visitors are accessing. Here‘s why:
It Looks Really, Really Bad
Put yourself in a regular user‘s shoes. You‘re browsing a site for the first time, trying to read a blog post or check out a product, when suddenly you‘re bombarded with a wall of incomprehensible techno-jargon that looks like this:
Notice: Undefined variable: post in /var/www/html/wp-content/themes/my-theme/single.php on line 25
Warning: Cannot modify header information - headers already sent by (output started at /var/www/html/wp-content/themes/my-theme/single.php:25) in /var/www/html/wp-includes/pluggable.php on line 1121How would you react? If you‘re like most people, you‘d probably think:
- This site looks glitchy and untrustworthy, I‘m outta here!
- Wow, this is way over my head, I have no clue what any of that means
- Is this one of those hacked sites that‘s going to give my computer a virus?!
Not exactly the impression you want to make, right? Showing raw PHP errors is a surefire way to make your site look unpolished and even sketchy to non-technical folks.
It Can Expose Sensitive Information
PHP errors don‘t just look bad, they can also reveal too much about the inner workings of your WordPress site. File paths, database table names, plugin and theme details – all of this back-end info can be used by bad actors to identify potential vulnerabilities and exploit them.
For example, an error referencing a specific plugin file like this:
Warning: include_once(/var/www/wp-content/plugins/vuln-plugin/inc/init.php): failed to open stream: No such file or directory in /var/www/wp-content/plugins/vuln-plugin/vuln-plugin.php on line 43Could tip off an attacker that your site is running an outdated version of a plugin with a known security flaw. They could then use that knowledge to craft a targeted attack.
The bottom line is, PHP errors have no business being displayed on any public-facing page on your production site, period. So let‘s look at how to turn them off the right way.
Step-by-Step Guide: Turning Off PHP Error Display in WordPress {#steps}
There are a few different ways to disable PHP error display in WordPress, but the simplest and most direct is by adding a snippet to your site‘s wp-config.php file.
Here‘s how to do it:
Open up your WordPress root directory via FTP, SFTP, or your hosting account‘s file manager
Look for the
wp-config.phpfile and download a copy to your computer as a backup (safety first!)Open the original
wp-config.phpfile in your favorite code editorFind this line:
define(‘WP_DEBUG‘, true);If you don‘t see that exact line, look for
define(‘WP_DEBUG‘, false);instead.Replace the WP_DEBUG line with this code block:
// Turn off error display ini_set(‘display_errors‘, ‘Off‘); ini_set(‘error_reporting‘, E_ALL ); define(‘WP_DEBUG‘, false); define(‘WP_DEBUG_DISPLAY‘, false);Save the edited file
Upload it back to your server, overwriting the original
wp-config.phpfile
Here‘s what the changes will look like:
With those settings in place, here‘s what each line does:
ini_set(‘display_errors‘, ‘Off‘)tells PHP not to output any errors to the browserini_set(‘error_reporting‘, E_ALL )instructs PHP to still log all errors behind the scenesdefine(‘WP_DEBUG‘, false)turns off WordPress‘ debug modedefine(‘WP_DEBUG_DISPLAY‘, false)disables displaying errors and warnings inside WordPress
Basically, you‘re telling both PHP and WordPress to pipe down with the errors on the front-end, while still keeping track of them in the background for your own reference later.
Verifying the Changes
Once you‘ve uploaded the modified wp-config.php file, load up a few pages on your WordPress site to make sure the errors have disappeared.
If you‘re still seeing some errors, double-check that your wp-config.php edits are correct and saved. You may also need to clear your browser cache and/or your WordPress cache plugin if you‘re using one.
Viewing PHP Error Logs for Debugging {#logs}
Now that you‘ve silenced PHP errors on the front-end, you might be wondering how you can still access them for debugging purposes.
Don‘t worry, they haven‘t vanished into thin air – PHP is still dutifully logging them to an error log file behind the scenes. You just need to know where to look.
The location of the PHP error log varies depending on your hosting environment, but here are some common default spots:
/var/log/php_errors.log/var/log/apache2/error.log/var/log/php/error.log/var/log/nginx/error.log
If you‘re not sure where yours is located, check your hosting account‘s documentation or reach out to their support team for guidance. Many managed WordPress hosts also provide convenient access to error logs through their control panel.
To view the contents of the PHP error log, you can either download it via FTP/SFTP or use the command line to tail the file in real-time as errors occur. Here‘s an example command to tail the last 100 lines of an error log and continue watching for new entries:
tail -n 100 -f /var/log/php_errors.logFiltering Out the Noise
One downside of relying solely on the PHP error log is that it can quickly become cluttered with extraneous notices and warnings that aren‘t actually impacting your site‘s functionality.
To zero in on the most critical errors only, you can add a filter to the error_reporting level by replacing E_ALL in the wp-config.php snippet with one of these values:
E_ERROR | E_WARNING | E_PARSE(only show errors, warnings, and parse errors)E_ERROR | E_PARSE(only errors and parse errors)E_COMPILE_ERROR | E_CORE_ERROR | E_ERROR | E_PARSE(only fatal errors)
For example:
ini_set(‘error_reporting‘, E_ERROR | E_WARNING | E_PARSE);Enabling WordPress Debug Logging
If you‘d rather have WordPress-specific errors logged to a separate file from the main PHP error log, you can enable WordPress‘ built-in debug logging with this setting in wp-config.php:
define( ‘WP_DEBUG_LOG‘, true );With that setting enabled, WordPress will create a debug.log file inside the /wp-content/ directory and log errors and warnings there. Just be sure to periodically clear out or rotate the log file so it doesn‘t balloon up and eat up storage space.
Plugin and .htaccess Alternatives {#alternatives}
I always recommend using the wp-config.php method described above as the most direct and reliable way to control error display in WordPress. But if for some reason you don‘t have access to edit that file directly, here are a couple of alternative methods:
Using a Plugin
Some PHP performance optimization plugins, like Query Monitor or Sentry, include an option to suppress error display. However, installing an additional plugin just for this purpose is overkill and can needlessly slow down your site. Plus, you‘re relying on the plugin to play nicely with WordPress core, which is not guaranteed.
That said, it‘s worth checking the settings of any plugins you already have installed to see if they offer error handling options. For example, some security and firewall plugins may have a setting to hide server errors as part of their hardening features.
Editing .htaccess
If you‘re using Apache as your web server, you can add the following lines to your .htaccess file to turn off PHP error display:
php_flag display_startup_errors off
php_flag display_errors off
php_flag html_errors off Place that code block above the standard WordPress rewrite rules.
Keep in mind that not all hosting setups will honor these .htaccess directives, so it‘s not a surefire solution. When in doubt, go with wp-config.php.
WordPress PHP Error Handling Best Practices {#best-practices}
To keep your WordPress site humming along without those pesky PHP errors popping up, follow these dos and don‘ts:
✅ DO:
- Disable PHP error display on your live production site
- Use the
wp-config.phpmethod for maximum compatibility - Leave error logging enabled to capture issues behind the scenes
- Periodically review error logs and fix the underlying bugs
- Set
WP_DEBUGtotrueon development/staging sites only - Keep WordPress core, plugins, and themes updated
🚫 DON‘T:
- Assume no news is good news – no visible errors doesn‘t mean no errors, period
- Let hidden errors pile up indefinitely without addressing them
- Rely on a plugin to handle error suppression if you can avoid it
- Expose
/wp-content/debug.logpublicly if you‘re using WP_DEBUG_LOG
By following these error handling best practices and staying vigilant about monitoring logs, you‘ll keep your WordPress site buttoned-up and professional for your visitors while still being able to squash bugs efficiently behind the scenes.
Frequently Asked Questions
Will disabling error display in wp-config.php hide ALL errors from visitors?
Yes, adding the ini_set(‘display_errors‘, ‘Off‘); line to wp-config.php will prevent any PHP errors from being output to the browser, including notices, warnings, and fatal errors. However, it‘s still best to also set WP_DEBUG and WP_DEBUG_DISPLAY to false to cover all your bases.
Is it okay to leave WP_DEBUG set to true on a live site if WP_DEBUG_DISPLAY is false?
While technically this would prevent errors from showing to visitors, it‘s still not recommended to leave WP_DEBUG enabled on a production site. Having debug mode on can introduce other issues and is really intended for local development environments only.
What‘s the difference between WordPress‘ built-in error logging and PHP‘s error_log?
WordPress‘ debug log (WP_DEBUG_LOG) is specific to errors and warnings generated by WordPress core, plugins, and themes. PHP‘s error_log is broader and will capture errors from any PHP script running on the server, including but not limited to WordPress. It‘s a good idea to keep an eye on both logs to get a comprehensive view of your site‘s health.
Wrapping Up
Well there you have it, folks – the complete guide to banishing PHP errors from your WordPress site‘s front-end while still leveraging them for debugging behind the curtain.
By adding a few strategic lines to your wp-config.php file, you can silence those unsightly notices and warnings for your visitors while still staying on top of errors with comprehensive logging.
But as satisfying as it is to sweep errors under the rug, don‘t forget that they‘re ultimately symptoms of deeper underlying issues with your site‘s code and configuration.
Whenever possible, make a habit of tracing errors back to their source and fixing them for good, rather than just slapping a "nothing to see here" coat of paint over them. Your site will thank you in the long run!
Now go forth and build error-free (or at least error-hiding) WordPress sites with confidence. 💪
){kind=link}