WordPress PHP compatibility is a property of the installed application, not a badge you can read from one plugin description. Core might support the target version while an invoice add-on, a must-use plugin or an old integration still blocks the move.
The difficult part is often the code between the obvious components. A theme calls a helper from a plugin. A scheduled task uses another PHP executable. A bundled library expects an extension that the new pool does not load. The plugin list alone does not show those relationships.
This walkthrough builds a compatibility record you can use to approve a release, assign repairs or explain why an upgrade needs more preparation. It combines documentation, source checks and real workflow tests because each answers a different question.
Define what compatible means for this project
Begin with the intended runtime and the application release being reviewed. Record the source commit or package versions. Otherwise, a developer can scan one set of files while an administrator updates another set on staging.
Then define the support range. Are you moving one controlled site to PHP 8.5, or maintaining a plugin that must also run on 8.3? The second case requires tests across that range, not just a successful run on the newest environment.
Use the WordPress core compatibility table for core’s stated support. Keep its scope clear. The table cannot assess custom code installed on a particular client site.
Write an acceptance statement such as: “The recorded application release completes the agreed enquiry and payment workflows on the target runtime, with no unexplained new errors.” That gives the audit a useful finish line.
Inventory the components that ordinary screens hide
The WordPress dashboard is a starting point. Include active and inactive plugins, must-use code, drop-ins, the active theme and any child theme. Review inactive components too if the business expects to activate them later.
With authorised shell access, these read-only commands produce a useful inventory:
# Run from the intended WordPress installation.
wp core version
wp plugin list --fields=name,status,version,update --format=csv
wp theme list --fields=name,status,version,update --format=csv
# Document CLI PHP separately from the website handler.
php -v
php --ini
php -mThe WP-CLI plugin-list documentation explains the available fields and statuses. Keep the export with the audit rather than relying on a screenshot that hides long names or installed versions.
Now add what those commands do not explain: snippets stored by a code-management plugin, custom endpoints, generated files, deployment scripts and hard-coded cron commands. Record where each item comes from and who can update it.
Do not publish the raw inventory if it includes private paths or application details. It is a technical working document for the responsible team.
Read vendor claims precisely
Look for compatibility notes that match the installed product and release. A current product page may describe an update the site has not installed. A support answer for the free edition may not cover the commercial add-on that handles checkout.
Also distinguish “Requires PHP” from proof that a component works on every newer release. A minimum requirement expresses a lower boundary. It is not a complete matrix of tested environments.
Ask useful questions when the documentation is vague. Which release supports the proposed target? Are there known limitations? Does the update require a database migration or a matching companion plugin?
If the vendor no longer maintains a critical dependency, turn that into a project decision. Replacing it, repairing it under an appropriate licence or isolating its workflow can each require different work. Hiding the issue under “test later” does not remove the dependency.
Use static analysis as a map of likely problems
Static tools inspect source without performing every application action. They can identify suspicious syntax, deprecated calls and version-specific patterns before a tester reaches the affected screen.
For WordPress projects, PHPCompatibilityWP provides a WordPress-oriented ruleset. Confirm that the installed tool versions cover the PHP target you intend to assess. An old scanner cannot prove compatibility with a release it does not understand.
# Example for a project with a compatible PHPCS toolchain installed.
# Replace the path and test range with the project's real requirements.
./vendor/bin/phpcs \
--standard=PHPCompatibilityWP \
--runtime-set testVersion 8.3-8.5 \
wp-content/plugins/client-integrationRun analysis in a controlled development or CI environment. Check the tool’s exit status and coverage notes. A command that failed to load its standard has not produced a clean compatibility result.
Review findings before changing code. Some need a repair; others need context or a tool update. Keep intentional exclusions documented so that the next developer knows why a directory or warning was ignored.
Check Composer packages under the target runtime
Where the project uses Composer, inspect the lock file and declared platform requirements. Bundled dependencies can block an upgrade even when the surrounding WordPress plugin looks simple.
# Run with the intended PHP interpreter and project dependencies.
composer validate --strict
composer check-platform-reqs --no-dev
composer prohibits php 8.5Consult the Composer command reference. These commands inspect different aspects of the package setup; none replaces a functional test of the site. If development tools also run on the target, check their requirements separately.
Do not use an ignore-platform flag as evidence that requirements are satisfied. It can force an installation past the very boundary you are trying to understand.
For a vendor plugin that bundles its own libraries, avoid running an uncontrolled dependency update inside the installed production package. Obtain a supported release or make a reviewed source change through the project’s deployment process.
Read the migration notes for the whole journey
The PHP 8.5 migration guide covers the move from 8.4. If the starting point is older, inspect the intervening guides too. A large version jump can encounter changes introduced several releases before the final target.
Separate incompatible changes from deprecations and new features. That distinction helps prioritise repairs. A parse error that prevents a file loading is different from a deprecation in a rarely used export, although both deserve an owner and a resolution plan.
Pay attention to input assumptions. External services and old database records can supply values that a developer’s ideal test data never includes. Review error handling around those boundaries rather than simply changing a function signature until a warning stops.
Keep the specific migration reference beside the finding. It makes the repair easier to review and reduces arguments based on remembered behaviour from another PHP version.
Match the server environment before blaming the code
Compare web and command-line PHP versions, extension lists and relevant settings. Confirm database drivers, image processing, internationalisation and any application-specific requirements.
On a managed host, ask which configuration applies to the selected domain and which applies to scheduled jobs. On a container platform, record the actual deployed image rather than the developer’s local tag.
A missing extension can look like a plugin defect. A command running under the wrong interpreter can look like a failed migration. Establishing the environment first prevents repairs aimed at the wrong layer.
For stores, use the WooCommerce server recommendations as another reference, then include requirements from the installed payment, subscription and reporting extensions. The store’s real stack can be broader than core WooCommerce.
Turn findings into a release decision
Use a small table instead of an unfiltered pile of scanner output:
| Finding | Owner | Required action | Release consequence |
|---|---|---|---|
| Removed or incompatible call in custom code | Application developer | Repair and test the affected path | Block release until resolved |
| Vendor compatibility uncertain | Product owner or vendor | Obtain support evidence and run representative tests | Record the unresolved risk |
| Required extension missing | Hosting administrator | Supply it on the target environment | Retest the dependent feature |
| New deprecation in a supported workflow | Responsible code owner | Assess output, logging and repair priority | Agree a documented decision |
| Background job uses old PHP | Operations owner | Correct the executable and verify a run | Keep the job in acceptance testing |
The table is a working example, not a universal severity policy. Adapt the release consequence to the application and the business impact.
Then repeat the important workflows under the target runtime. Save the expected and actual records: an enquiry entry, an approved test order, a generated document or a completed import. Record failures clearly enough for another person to reproduce them.
Track the relationship behind a failure
When a workflow crosses several components, record the dependency chain. A quote form might call a custom hook, load a bundled HTTP library and send data to a CRM. Each component can pass its own isolated test while the combined workflow fails on an unexpected response.
Choose representative cases along that chain. Include an empty optional value, a rejected response and the retry path where the application supports one. Check that the original submission remains recoverable when the next service is unavailable.
Assign the repair to the component that owns the failing behaviour. Editing the form template will not solve a platform requirement in its HTTP library. This short relationship map often makes the audit more useful than adding another page of unreviewed warnings.
What a useful compatibility handover includes
Deliver the component inventory, environment details, reviewed findings, repair references and test outcomes. State what was outside the test scope. A payment method you could not exercise should remain visible as a limitation.
Keep the approved versions together as one release baseline. If someone updates a critical plugin afterwards, review the affected evidence rather than assuming the old compatibility result covers the new package.
WordPress PHP compatibility becomes much easier to maintain when the audit is repeatable. The next update starts from a known stack and a short acceptance list, rather than another anxious click in the hosting panel.
For inherited sites, my security takeover guide covers the access and ownership work around that baseline. To scope a specific audit, send the current PHP and WordPress versions plus the critical plugins.
