WordPress Supports Old PHP; Your Production Server Shouldn’t

By Greg Nowak. Last updated 2026-08-01.

A WordPress site can load perfectly well on a server stack that no longer belongs in production. WordPress 7.0 still supports PHP 7.4, even though WordPress recommends PHP 8.3 or newer and warns that legacy releases have reached end of life.

The distinction is easy to miss. WordPress’s minimum requirement tells you whether core can run. It says nothing about whether that PHP branch still receives security fixes, or whether the rest of the site is ready for a maintained version.

For an agency or organisation responsible for several sites, waiting tends to make the eventual move harder. Plugins change, themes fall behind, custom code accumulates and server dependencies become less familiar. The answer is a repeatable upgrade process: inventory the estate, test representative sites, fix what breaks and deploy in controlled stages.

Compatibility is only the starting point

The official WordPress requirements recommend PHP 8.3 or greater for performance and security. The same page says WordPress will still run on PHP 7.4, while warning that legacy PHP may expose a site to security vulnerabilities.

Both statements make sense in context. WordPress maintains a low compatibility floor because it has to work across a vast, uneven hosting market. A production owner has a narrower job: choose a maintained PHP release that works with the complete application.

That application includes core, active and inactive plugins, the theme, custom PHP, required extensions, scheduled tasks, command-line jobs and server configuration. Core support matters, but it cannot answer for the whole stack.

PHP 8.2 is already a short-term destination

The PHP project’s lifecycle table shows that PHP 8.2 receives critical security fixes only until 31 December 2026. PHP 8.3 remains under security support through 2027. PHP 8.4 and 8.5 have longer maintenance windows.

This affects the target you choose now. Moving an old site to PHP 8.2 may remove an immediate problem, only to leave another migration due within months. PHP 8.3 meets the current WordPress recommendation, but PHP 8.4 or 8.5 may offer a better runway when the installed WordPress version, plugins, theme and infrastructure support them.

“Beta support” is no longer a reason to wait

One familiar argument for delaying an upgrade has fallen away. In its spring 2026 support clarification, the WordPress core team retired the “beta support” label for PHP 8 releases. WordPress now documents full PHP 8.3 support from version 6.4, full PHP 8.4 support from version 6.8, and full PHP 8.5 support in versions 6.9 and 7.0.

That does not make every plugin or theme compatible overnight. WordPress itself acknowledges that core is rarely used alone. What has changed is the question: instead of debating PHP 8 support in general, you can test whether a particular site works on the chosen branch.

Find the problems before the production switch

Start with an inventory. Record the PHP version for every site, along with the version used by related command-line and scheduled processes. Note required extensions and identify shared hosting pools, server templates or containers where one runtime change could affect several properties.

Then group sites with genuinely similar configurations. Installations that share a WordPress generation, theme family, plugin set and custom code may use the same test lane. Business-critical sites and unusual builds deserve separate clones. This saves duplicated effort without assuming that every WordPress installation will fail in the same way.

A workable upgrade process has five parts:

1. Choose the target version. Check the installed WordPress release, PHP’s remaining support window and the compatibility position of every maintained dependency. The smallest possible version jump is not automatically the safest investment.
2. Build a production-like clone. Match the important PHP extensions and configuration closely enough to reveal environment-specific failures. Isolate the clone from live email, payments and third-party writes.
3. Test the real application. Cover public templates, login, publishing, forms, search, scheduled tasks, integrations and administrative work. Automated tests help, but they should sit alongside checks of the journeys the site actually depends on.
4. Trace and repair failures. Review deprecations, warnings, uncaught exceptions and fatal errors. Assign each finding to core, a dependency, custom code or server configuration, then update, replace or repair the responsible component.
5. Rehearse deployment and rollback. Document the version switch, configuration changes, cache handling, validation checks and rollback trigger before the production window begins.

Use isolated tests for faster coverage

The current WordPress Playground CLI testing guide offers a practical way to test plugin and theme code across selected PHP and WordPress versions. A project can be mounted into a clean WordPress installation, while the CLI’s --php and --wp options run PHPUnit against combinations from PHP 7.4 through 8.5.

This makes compatibility testing repeatable. The same code can be exercised against its present runtime and the proposed replacement, and clean installations help separate code failures from years of accumulated site state.

Playground is one layer of testing, not a substitute for a production-like clone. Unit tests may miss server extensions, real content, third-party services, asynchronous jobs and complete browser journeys. Use it for quick, isolated checks, then test the representative application in an environment that resembles production.

Roll out according to risk

After a target passes testing, deploy it to a low-risk production site or a small cohort before moving the whole fleet. Check visible behaviour and server-side signals. Leave enough observation time to cover important scheduled and editorial activity; one successful page request proves very little.

Agree on rollback conditions beforehand. A fatal error, failed checkout, broken publishing workflow or sustained abnormal error rate should trigger a known response during the maintenance window. Keep the former runtime and configuration available until the replacement has passed the agreed observation period.

Keep the inventory and test matrix when the work is finished. PHP maintenance will come around again as branches move from active support to security-only maintenance and then end of life. Reusing the same upgrade lane turns the next deadline into planned server work.

What a practical PHP upgrade engagement covers

Greg can help map PHP versions and extensions across a WordPress fleet, identify representative sites, and test plugins, themes and custom code on PHP 8.3 through 8.5. The engagement can also cover warning and fatal-error analysis, repairs to incompatible PHP, performance comparisons under representative workloads, and staged server rollouts with monitoring and rollback.

The useful output is not a vague “compatible” verdict. It is a documented target version, a clear record of blockers and repairs, repeatable test coverage, and a deployment plan tied to the fleet’s real risks. That gives the people responsible for production a sound basis for deciding when and how to switch.

Related on GrN.dk

• A Voice Agent Is Only Ready When the Human Handoff Works
• If the Facts Need JavaScript, AI Search May Miss the Full Page
• Background AI Tasks Need Queues, Not Just Longer API Calls

Need help with this kind of work?

Plan a controlled PHP upgrade Get in touch with Greg.

Sources

• WordPress hosting requirements
• WordPress PHP support clarification, spring 2026
• Testing PHP versions with WordPress Playground CLI
• PHP supported versions