Title: PHP error reporting Author: WordPress VIP Documentation Published: July 20, 2022 Last modified: September 4, 2025 --- 1. [WordPress on VIP](https://docs.wpvip.com/wordpress-on-vip/) 2. [PHP](https://docs.wpvip.com/wordpress-on-vip/php/) 3. PHP error reporting # PHP error reporting Output from PHP error reporting can be helpful for debugging issues in application code. ## Settings for reporting levels PHP error reporting levels for WordPress environments on the VIP Platform are defined by platform-level settings, WordPress Core, and custom settings added to application code.  A `php.ini` configuration file sets a default of all PHP error reporting to be enabled for a WordPress environment except for notices, deprecation notices, and strict notices: `error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_STRICT` Though `E_STRICT` is included, it is redundant in this setting since [PHP 7 reassigned all instances of E_STRICT](https://wiki.php.net/rfc/reclassify_e_strict) to other levels. When WordPress loads, it [updates the PHP error reporting](https://github.com/WordPress/WordPress/blob/bbe60d66c32c9a0b401b15e32fa28db958509c65/wp-includes/load.php#L481) settings to enable: `E_CORE_ERROR | E_CORE_WARNING | E_COMPILE_ERROR | E_ERROR | E_WARNING | E_PARSE | E_USER_ERROR | E_USER_WARNING | E_RECOVERABLE_ERROR`. Note that this means deprecations are not reported by default. Based on the PHP error reporting settings with WordPress loaded, if `echo [error_reporting()](https://www.php.net/manual/en/function.error-reporting.php)` was called in application code with no arguments, the [reporting level](https://maximivanov.github.io/php-error-reporting-calculator/) value `4983` would be returned. ## Error report output By default, `WP_DEBUG` is defined as `false` on production environments and `true` on non-production environments. **Note** When `WP_DEBUG` is defined as `true`, all error output will appear in the rendered page HTML. For this reason, configurations should not be set to enable `WP_DEBUG_DISPLAY` on a production environment unless it is [unlaunched](https://docs-admin-wpvip-com-staging-content.go-vip.net/docs-vip/unlaunched/). Most default values of [WordPress debugging constants](https://wordpress.org/support/article/debugging-in-wordpress/) can be overridden and set per-environment by defining the constants with the desired values in [`vip-config/vip-config.php`](https://docs.wpvip.com/wordpress-skeleton/vip-config-directory/) of the branch deploying to that environment. * On VIP Platform environments, `[WP_DEBUG_LOG](https://wordpress.org/support/article/debugging-in-wordpress/#wp_debug_log)` is set to false and cannot be overridden. * By default,`[WP_DEBUG_DISPLAY](https://wordpress.org/support/article/debugging-in-wordpress/#wp_debug_display)` and `[WP_DEBUG](https://wordpress.org/support/article/debugging-in-wordpress/#wp_debug)` are not defined and as a result, will load as `false` unless overridden. * Even if overridden and defined as `true`, `WP_DEBUG_DISPLAY` (and `WP_DEBUG_LOG` if enabled on local environments) will perform no function unless`WP_DEBUG` is _also_ defined as `true`. When `WP_DEBUG` is defined as `true`, WordPress [sets `E_ALL`](http://github.com/WordPress/WordPress/blob/bbe60d66c32c9a0b401b15e32fa28db958509c65/wp-includes/load.php#L460)( all errors, warnings, notices and deprecations). If `WP_DEBUG_DISPLAY` is also defined as `true`, the ini setting `[display_errors](https://www.php.net/manual/en/errorfunc.configuration.php#ini.display-errors)` will be enabled, and error output will appear in the rendered page HTML. Other than the situational exceptions described above, there are no differences between error reporting levels for production or non-production environments—[launched](https://docs.wpvip.com/launched/) or unlaunched—or between environments running different versions of PHP. ## Logging Logged error output for a VIP Platform environment can be retrieved in [the VIP Dashboard Runtime Logs panel](https://docs.wpvip.com/logs/runtime-logs/dashboard/) or with [the VIP-CLI Runtime Logs command](https://docs.wpvip.com/logs/runtime-logs/cli/). ### Manually log errors to Runtime Logs with PHP For debugging purposes, custom errors can be manually logged in PHP on any environment. Though `trigger_error()` and `error_log()` can both be used to log messages to [Runtime Logs](https://docs.wpvip.com/logs/runtime-logs/), it is recommended to use `trigger_error()` whenever possible. `trigger_error()` allows the VIP Platform’s built-in error handler to be used. The built-in error handler automatically includes a debug backtrace in an error message which makes it easier to trace and diagnose issues. Additionally, `trigger_error()` supports custom error types, and can be handled via a custom error handler if it is defined in an application. Refer to the PHP manual for more usage details for `[trigger_error()](https://www.php.net/manual/en/function.trigger-error.php)` and `[error_log()](https://www.php.net/manual/en/function.error-log.php)`. ### Logging on local environments [VIP’s WordPress Skeleton codebase](https://github.com/Automattic/vip-go-skeleton) defines `WP_DEBUG` as `true` for local environments and non-production environments. This makes PHP Deprecations, Notices, Warnings, and Errors available during development. On a [VIP Local Development Environment](https://docs.wpvip.com/vip-local-development-environment/), debugging output can be retrieved with the [VIP-CLI command ](https://docs.wpvip.com/vip-cli/commands/dev-env/logs/)` [vip dev-env logs](https://docs.wpvip.com/vip-cli/commands/dev-env/logs/) --slug = --service=php`. When using other local development applications, `WP_DEBUG_LOG` and `WP_DEBUG` must both be defined as `true` in order to log error output. Last updated: September 04, 2025