Guide
WordPress Silent PHP Errors: How to Find Errors Nobody Sees
Production WordPress sites suppress error display. That’s correct. But suppressing display is not the same as handling errors. Here’s how to find and monitor the errors nobody sees.
Why PHP errors are silent in production
Every WordPress production site should have display_errors = Off and WP_DEBUG = false. Showing errors to users is a security risk and a bad experience. But this creates a blind spot: errors still happen, they just happen invisibly.
PHP warnings, deprecation notices, and even fatal errors can be caught by WordPress’s error handler and suppressed. The page still renders. The site still loads. But functionality is broken.
Silent PHP errors that actually break things
- Deprecation → fatal on PHP 8.2+ - A function deprecated in PHP 8.0 becomes a fatal error in 8.2. The error handler catches it, but the function never executes.
- Plugin conflict producing warnings - Warnings on every request that slow the site by 200ms each. Invisible unless you check error logs.
- Database errors in non-critical paths - A query fails in a sidebar widget. The page renders without the widget. Nobody notices for months.
- REST API endpoint returning 500 - A Gutenberg block can’t save because a REST endpoint throws a PHP error. The editor shows a generic message.
How to find silent PHP errors manually
1. Enable debug logging
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
Errors go to wp-content/debug.log. The problem: this file grows without limit, nobody reads it, and it requires manual inspection.
2. Check server error logs
Apache: /var/log/apache2/error.log. Nginx: /var/log/nginx/error.log. Same problem - large files, no structure, no alerting.
Monitoring WordPress PHP errors automatically
Logystera captures PHP error events and categorizes them by severity, source file, and frequency. You see which errors are occurring, how often, and whether the rate is increasing. A spike in errors after a plugin update is visible immediately.
What Logystera tracks:
- Error rate by severity (notice, warning, fatal, deprecation)
- Error source - which file and line number
- Error frequency trends - is it getting worse?
- Alerts when error rate spikes after a deployment or update
Real example: search broken for 6 weeks
A Drupal module update introduced a PHP 8.2 deprecation in the search indexer. The error handler caught it. Pages still rendered. But the search index stopped updating. For six weeks, users got increasingly stale search results. Nobody connected it to the update.
Logystera would have shown a new PHP deprecation error appearing immediately after the update, with the exact file and line number.
Your logs already know
Silent PHP errors are already recorded in your logs. The question is whether anyone is analyzing them.
Logystera doesn’t guess. It derives truth from logs.
Related Logystera content
Frequently asked questions
Why doesn't WordPress show PHP errors in production?
Showing errors to visitors leaks server paths, plugin names, and code structure — that's a security problem. Best practice is WP_DEBUG_DISPLAY = false (don't show users), WP_DEBUG_LOG = true (write to file), and ship the file to a monitoring system that watches for new errors.
What's the difference between a fatal, an error, a warning, and a notice?
Fatal: PHP cannot continue, the request dies (white screen or "There has been a critical error"). Error (E_ERROR): like fatal but slightly different code paths in older PHP. Warning: something is wrong but execution continues — often the precursor to a fatal. Notice: minor issue (undefined variable, typo) — usually safe to ignore individually but a flood of them indicates code rot.
Should I fix every notice and warning?
On a healthy codebase, yes — they're always real bugs even if they don't crash anything today. On a legacy site with thousands of notices from third-party plugins, prioritize: fix everything in your own theme/plugins first, then the highest-volume warnings from third-party code. A flood of notices makes it impossible to spot the real fatal when it appears.
Where does WordPress write PHP errors?
When WP_DEBUG_LOG is enabled, errors go to /wp-content/debug.log. You can override the location with WP_DEBUG_LOG = "/path/to/file.log". Some hosts redirect to system logs (/var/log/php-error.log or similar) — check your host's docs. Without WP_DEBUG_LOG, errors go to whatever PHP's error_log directive points to, often /dev/null on shared hosting.
See what's actually happening in your WordPress system
Connect your site. Logystera starts monitoring within minutes.
