| 开发者 | dhanendran |
|---|---|
| 更新时间 | 2026年6月18日 12:03 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.0 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
deprecated_function_run, deprecated_hook_run, doing_it_wrong_run, and friends) as your site runs. Because those signals fire regardless of WP_DEBUG, you catch real deprecations on production without turning on debug mode — each one attributed to the plugin or theme that triggered it.wp readiness check prints the full report and exits non-zero on a red verdict, so you can gate upgrades in CI/staging.upgrade-readiness-monitor folder to /wp-content/plugins/, or install it from the Plugins screen.No. It only reads and reports. Deprecation notices are captured passively and stored locally; the audit reads plugin/theme headers, public WordPress.org data, and your plugins'/theme's own PHP files.
No. WordPress fires its deprecation hooks whether or not WP_DEBUG is enabled, so the monitor works on production.
"Error" findings are conservative and high-confidence: they come from a hand-verified list of PHP functions genuinely removed in the target PHP version (calling them is a fatal error). "Warning" findings are deprecations — code that still works but emits a notice on the target. The WordPress deprecation list for your target version is read from WordPress core itself. The scan is precise rather than exhaustive: it reports problems it is confident about and never invents findings. It does not execute your code, so a clean result is not an absolute guarantee — always do a final test on staging — but a red verdict means there is real, specific breakage to fix first.
If WordPress.org can't be reached, the target-version deprecation check is simply skipped (you still get the PHP checks, metadata signals, and runtime capture). The plugin never fabricates results from missing data.
wp readiness check WP-CLI command.