By Greg Nowak. Updated 21 October 2026.
A working homepage is a poor measure of server health. WordPress can still run on PHP versions that no longer receive fixes from the PHP project. Meanwhile, the features your business depends on—enquiries, checkout, publishing and integrations—may only reveal compatibility problems when someone uses them.
The practical response is a planned upgrade: choose a maintained PHP version, test the complete site and agree how to recover if production behaves differently.
WordPress compatibility is a starting point
The official WordPress requirements recommend PHP 8.3 or newer, while retaining compatibility with PHP 7.4 and warning about the risks of legacy versions. That minimum tells you whether WordPress core can run. It does not establish a suitable maintenance policy for your business.
Your application also includes plugins, themes, custom code, PHP extensions and background jobs. A supported WordPress and PHP combination is necessary, but the whole installation needs checking. Keep the chosen PHP branch updated to its latest supported patch release, too.
Which PHP version should you choose?
As of October 2026, PHP 8.2 has little maintenance time left. The PHP support calendar gives these security support deadlines:
| PHP branch | Security support ends | Practical upgrade decision |
|---|---|---|
| 8.2 | 31 December 2026 | Use only as a temporary bridge with a follow-up upgrade scheduled. |
| 8.3 | 31 December 2027 | A fallback where dependencies prevent adopting a newer branch. |
| 8.4 | 31 December 2028 | A useful candidate to test for a longer maintenance window. |
| 8.5 | 31 December 2029 | The longest window listed here, subject to application and hosting compatibility. |
WordPress’s 2026 support clarification retired the PHP “beta support” label. It documents full PHP 8.3 support from WordPress 6.4, PHP 8.4 support from 6.8, and PHP 8.5 support in 6.9 and 7.0. These compatibility milestones do not justify leaving WordPress itself outdated.
I would assess PHP 8.4 and 8.5 first for an upgrade planned now. If a dependency blocks both, record the blocker, its owner and a review date before settling on 8.3.
Start with an inventory and a named owner
For each site, record its WordPress version, web PHP version, plugins, theme, custom code and required extensions. Check command-line scripts and scheduled jobs separately: they may use a different PHP executable from the website.
Also identify shared hosting pools or server configurations where one change affects several sites. Agencies can group similar installations for initial testing, but should validate each production site’s important workflows.
Give the work an owner who can coordinate hosting access, dependency updates, business testing and deployment. Otherwise, a known compatibility issue can sit between the agency and hosting provider without anyone resolving it.
Test the work people actually do
Create a protected staging copy with representative content, matching extensions and relevant PHP settings. Block indexing and prevent live emails, payments, webhooks and other external writes. Confirm that backups can be restored before making changes.
Build the test checklist around business activity:
- Customer journeys: submit an enquiry, complete a test checkout, search and access restricted content where applicable.
- Editorial work: log in, edit and publish content, upload images and check previews.
- Background activity: exercise scheduled publishing, imports, exports, queues and integrations.
- Technical signals: inspect PHP logs, failed requests and response times under comparable conditions.
Check outcomes as well as screens. A form displaying a success message is insufficient if its notification or CRM update fails. Ask the people who use the site to confirm their workflows.
Assign each failure to its cause: a dependency, custom code or server configuration. Update, repair or replace the responsible component, then repeat the affected checks. Review deprecation notices as maintenance work even when they do not stop the upgrade.
Use isolated tests to catch code problems earlier
For teams maintaining plugins or themes, the Playground CLI PHPUnit guide documents isolated testing with selectable PHP and WordPress versions. With Composer dependencies installed and a configured PHPUnit suite, a plugin-directory example is:
npx @wp-playground/cli@latest php --auto-mount --php=8.5 --wp=7.0 -- /wordpress/wp-content/plugins/MY_PLUGIN/vendor/bin/phpunit -c /wordpress/wp-content/plugins/MY_PLUGIN/phpunit.xml.distReplace MY_PLUGIN and the configuration path with your project’s values. Use --php and --wp to repeat tests against the combinations you need to support.
This gives developers faster feedback. It complements staging checks; it cannot establish that production extensions, real content and external services all behave correctly.
Make rollback part of the deployment
Before switching production, write down the runtime change, required configuration, cache handling, validation checks and rollback trigger. Confirm that the previous runtime remains available during the observation period.
Separate PHP switching from unrelated database or application changes where practical. Reverting PHP does not reverse a plugin’s database migration. Restoring an older database can also discard orders, enquiries or edits received since the backup.
Start with a lower-risk site or small group. After deployment, repeat the critical journeys and monitor errors, integration failures and performance. Observe long enough to cover relevant scheduled jobs and normal editorial activity.
A failed checkout or broken publishing workflow needs an agreed response and someone available to carry it out. Keep the inventory, findings and test checklist afterwards so the next upgrade starts with evidence.
Need help planning the upgrade?
I can help assess your WordPress estate, investigate compatibility blockers and coordinate testing and rollout with your hosting provider or agency. The useful deliverables are a justified target version, assigned repairs and a deployment plan your team can execute. Contact Greg to discuss your PHP upgrade.
Related on GrN.dk
- How to Check Whether a PHP Constant Is Defined (Without Breaking Production)
- PHP 8.2 Has 103 Days Left: Audit the CMS Estate
- Upgrading PHP 5: Use PHP 7 as a Bridge, Not the Destination
Need help with this kind of work?
Discuss your WordPress PHP upgrade Get in touch with Greg.
