Auditing plugin update compatibility means reading what each plugin declares about the WordPress and PHP versions it supports, staging the exact update set on a copy of the site, and confirming your rollback safety net works before you touch production. The audit is a paperwork exercise followed by a rehearsal: collect declared version headers and dependency chains, run a dry-run update list, then apply the real updates on a staging clone with debugging on. That order matters because declared compatibility is a claim, not a test result. The checks below separate what a plugin's author has promised from what your particular stack actually does when the files change.
Table of Contents
- Read two files per plugin, not one
- What the admin screens tell you, and what they don't
- Map dependency chains before you stage anything
- Confirm the rollback safety net passes its own checks
- Set the environment type so the test site tells the truth
- Weighing a failed audit against the cost of waiting
- Frequently Asked Questions
Read two files per plugin, not one
Compatibility data is split across two locations, and auditing only one gives you half the picture. According to the WordPress Plugin Handbook's readme documentation, the "Tested up to" header in `readme.txt` records the highest WordPress version the developer has successfully tested against, while "Requires at least" and "Requires PHP" are read by core from the main plugin PHP file rather than the readme, a change that landed in WordPress 5.8. So for each plugin in `wp-content/plugins`, pull "Tested up to" from the readme and the two "Requires" values from the plugin's primary PHP file. A plugin declaring `Requires PHP: 8.1` on a server running 8.0 is a hard blocker you can find in seconds — no test site required.
The handbook also describes the yellow warning banner WordPress.org places on listings. Per the handbook's alerts and warnings page, that banner appears on any plugin not tested with the last three major WordPress releases, a rule that replaced the earlier "not updated in two years" trigger in 2018. Treat it as a maintenance signal about the author's attentiveness, not a verdict on whether the code runs. It is also distinct from a plugin being closed for guideline or security violations, which is a different and more serious state.
What the admin screens tell you, and what they don't
Inside wp-admin, the Plugins > Add New screen labels each listing either "Compatible with your version of WordPress" or "Untested with your version of WordPress." The handbook is explicit that this label reflects the author's declared value, not any actual test anyone ran. It is a fast per-plugin read without leaving the dashboard, and it is exactly as reliable as the header behind it.
The practical consequence: "Untested" is a prompt to investigate, not proof of breakage, and "Compatible" is not proof of safety. A well-maintained plugin whose author bumped the header on release day and a neglected one whose author bumps it reflexively look identical from the admin screen.
Map dependency chains before you stage anything
Since WordPress 6.5, version numbers are not the only ordering constraint. The Make WordPress Core dev note on plugin dependencies describes a `Requires Plugins` header that takes a comma-separated list of WordPress.org plugin slugs. Dependents cannot be installed or activated before their dependencies, and dependencies cannot be deactivated or deleted while a dependent is active. That changes the audit from a flat list into a graph. Grep your plugin files for `Requires Plugins` and sketch what depends on what, because a plugin you planned to deactivate as part of troubleshooting may be pinned in place by something else that is active.
Then stage the update set itself. The WP-CLI command reference documents `wp plugin update –all –dry-run`, which lists exactly which plugins would update and to what version while changing nothing. The `–minor` and `–patch` flags restrict updates to those semantic-versioning levels. A patch-only pass is a reasonable first wave; majors get their own slot. A workable sequence:.
- Capture `wp plugin update –all –dry-run` output and save it as the audit's definition of "this upgrade."
- Resolve blockers: PHP floors above your server version, plugins in a closed state, abandoned dependencies.
- Apply `–patch`, then `–minor`, then each major individually.
- Re-run the dry run after each wave to see what shifted.
Confirm the rollback safety net passes its own checks
WordPress has built-in recovery, but only if the prerequisites are met — which is itself an audit item. The Make WordPress Core dev note on 6.3 rollback explains that for failed manual plugin and theme updates, the existing version is copied to `wp-content/upgrade-temp-backup` and restored if the update fails. The same release added two Site Health checks: one for whether that backup folder is writable, and one for available disk space. Verify both pass before any bulk update, because a failing writability check quietly removes the restore path. Rollback for *auto-updates* arrived separately.
A Make Core merge proposal published 19 April 2024 describes it as a third phase after `move_dir()` in 6.2 and manual rollback in 6.3: it performs a loopback request to the home page and reverts the plugin if a fatal error appears. Two limits are worth writing into your runbook — it watches the home page, not your checkout or admin flows, and it does not check inactive plugins. Behind both sits recovery mode, added in WordPress 5.2. A Make Core dev note from 16 April 2019 explains that a fatal error after an update emails the admin a login link and pauses the offending plugin. It can be disabled with `WP_DISABLE_FATAL_ERROR_HANDLER` in `wp-config.php`, and it initializes only after MU plugins load — so a failure earlier than that bypasses it entirely. Check whether that constant is set on the site you are auditing, and confirm the admin email address actually receives mail.
Set the environment type so the test site tells the truth
A staging clone only surfaces problems if it is configured to report them. The Make Core dev note from 24 July 2020 introducing `wp_get_environment_type()` in WordPress 5.5 describes a function returning `local`, `development`, `staging` or `production`, read from the `WP_ENVIRONMENT_TYPE` constant or environment variable and defaulting to production. Hosts are asked to set `staging` on staging copies, and `development` turns `WP_DEBUG` on automatically.
That default is the trap. A cloned site inherits production behaviour and hides the deprecation notices and PHP warnings you cloned it to find. Set the constant explicitly on the copy, then exercise the paths that matter — checkout, forms, logged-in admin, cron, any REST endpoints you depend on — rather than only loading the home page.
Weighing a failed audit against the cost of waiting
When an audit flags a plugin as incompatible, the tempting answer is to defer the whole upgrade. That has its own price. Patchstack's 2025 security analysis recorded 11,334 new WordPress vulnerabilities that year, up 42% year over year, with 91% of them in plugins and 6 in core. Secondary write-ups of the same report quote a higher plugin share of 96–97%, so Patchstack's own 91% figure is the one to cite.
The useful read of those numbers is where the risk concentrates. Plugins, not core, are the surface — which means a deferral that keeps one incompatible plugin pinned at an old version is holding open the exact category of exposure the data describes. If a plugin cannot be updated, the decision is whether to replace it, not whether to wait indefinitely for its author. Document each blocker with the plugin slug, the current and target versions, the specific failure, and a date to revisit. An audit whose findings live only in a terminal buffer gets re-run from scratch next quarter.
Frequently Asked Questions
Does "Tested up to" matching my WordPress version mean the update is safe?
No. The WordPress Plugin Handbook describes it as the highest version the developer has successfully tested against — their claim about their own testing. It says nothing about your theme, your other plugins, or your PHP version.
Can I skip staging if WordPress 6.3 rollback is available?
Rollback covers an update that fails during the update process. A plugin that installs cleanly and then breaks your checkout page has not failed in that sense, and the auto-update rollback only loopback-tests the home page.
How do I find which plugins declare dependencies?
Search your plugin files for the `Requires Plugins` header introduced in WordPress 6.5. It holds a comma-separated list of WordPress.org slugs, and core enforces activation order from it.
Why does my staging site show no warnings when production has errors?
`wp_get_environment_type()` defaults to production, so a clone reports as production until you set `WP_ENVIRONMENT_TYPE`. Setting it to `development` turns `WP_DEBUG` on automatically.
You Might Also Like
- WordPress Maintenance: Staging Tests After Cloud Account Recovery: Which Integrations Should Be Checked Before Production?
- WordPress Maintenance: Media Files Linked From Google Drive: How to Find Dependencies Before Moving Storage
- WordPress Maintenance: Google Sheets Integrations After Account Restoration: How to Test Permissions Before Resuming Sync
