WordPress 7 Requires PHP 7.4: Upgrade to 8.3

WordPress 7.0 raised its minimum supported PHP version to 7.4, but minimum supported is not the same as recommended for production. WordPress currently recommends PHP 8.3 or greater, while PHP 7.4 has reached end of life. A site can pass WordPress’s core requirement and still be exposed to unpatched PHP vulnerabilities or fail because one plugin, theme, must-use plugin, or server extension is not ready for the new runtime.

This guide shows how to upgrade a WordPress 7 site to PHP 8.3 without using the live site as the compatibility test. You will inventory every runtime and code owner, build a representative staging copy, log failures privately, test real business workflows, deploy with a server-level rollback, and verify web, cron, queue, and command-line requests.

Quick answer: Confirm the web, command-line, and scheduled-task PHP versions; inventory WordPress, plugins, themes, must-use plugins, drop-ins, custom code, Composer packages, and required extensions; then create a current database-and-files backup plus a production-like staging site. Switch only staging to PHP 8.3, keep errors logged and hidden, and test admin, REST, cron, media, forms, email, login, checkout, webhooks, and CLI work. Repair the component named by evidence. For production, record the old PHP version and one-click rollback path, switch during a monitored window, run the same acceptance tests, and watch new logs before closing the change.

Separate the minimum from the recommended PHP version

Current PHP branch	What it means for WordPress 7	Practical action
7.3 or older	WordPress 7.0 does not support it	Do not update production to WordPress 7 until the PHP migration is tested
7.4	Core minimum, but the PHP branch is end of life	Use only as a short migration bridge; move to a supported branch
8.0 or 8.1	Compatible with WordPress 7 core, but those PHP branches are end of life	Test an upgrade to a currently supported branch
8.2	Compatible; PHP security support ends December 2026	Plan the next move instead of treating it as a long-term destination
8.3	WordPress’s current recommended baseline; PHP security support through 2027	Good conservative target when the full site stack passes testing
8.4 or 8.5	Listed as compatible with WordPress 7 core	Use when the host and every business-critical component explicitly pass your tests

Original Abdullahwp Php Upgrade Flow: Inventory Every Runtime, Prove Compatibility On Staging, Deploy With Rollback, And Verify Real Workflows.

Do not change PHP on production merely because WordPress core supports it. WordPress rarely runs alone. A premium plugin, old theme, custom integration, encrypted loader, missing extension, system cron command, or host-specific drop-in can fail even when the core compatibility table is green.

1. Record every PHP runtime and the current baseline

Start in Tools > Site Health > Info > Server. Record the WordPress version, web PHP version, server API, memory limit, time limit, database version, and active theme. Your host may expose different PHP selectors for the domain, subdomain, command line, scheduled jobs, and isolated application containers. Do not assume one control-panel dropdown changes all of them.

php -v
php --ini
php -m
wp --info
wp core version

Run command-line checks only when you have authorized SSH access and know the correct site path. If php -v differs from Site Health, the web server and CLI are using different binaries. That can make browser requests succeed while WP-CLI, Composer, a backup script, or system cron fails after the change.

Record the host’s exact old PHP branch and point release.
Export the loaded extensions and active php.ini paths for web and CLI.
Note the PHP handler or pool, OPcache configuration, and any per-directory .user.ini overrides.
List every domain, staging site, and application sharing the same PHP pool or selector.
Capture a healthy baseline for response time, error rate, queue depth, cron, orders, submissions, and email delivery.

2. Inventory code that WordPress’s core table cannot approve

WordPress’s compatibility table covers core. Build a separate ownership list for plugins, themes, must-use plugins, drop-ins such as object-cache.php, custom snippets, child-theme code, Composer dependencies, ionCube or other loaders, payment libraries, and host integrations. The WordPress plugin audit checklist provides a practical starting structure.

wp plugin list --fields=name,status,version,update,requires_php,tested_up_to
wp plugin list --status=must-use --fields=name,status,version
wp plugin list --status=dropin --fields=name,status,version
wp theme list --fields=name,status,version,update

A declared requires_php value tells you a minimum, not that the component has been tested on every newer PHP release. Missing metadata is unknown, not compatible. For commercial or custom code, check the vendor’s current release notes and support statement. Record the exact evidence and date; avoid relying on an undated forum reply.

Update or replace abandoned components through a separate tested change.
Identify plugins that cannot be updated until PHP changes, and plan the dependency order on staging.
Check custom command-line scripts and cron commands for hard-coded PHP binary paths.
Confirm required extensions such as cURL, DOM, EXIF, fileinfo, GD or Imagick, intl, mbstring, MySQLi, sodium, XML, and ZIP are present where the site needs them.
Keep licenses, API keys, webhook URLs, and environment secrets out of shared inventory files.

3. Prepare a backup and a PHP rollback that are different controls

A full database-and-files backup protects site data. A PHP rollback returns the server runtime to the previous branch. You need both. Confirm the host can switch the domain or PHP pool back quickly and that the old branch will remain available during the change window. Record who has permission to do it and how long a pool restart or configuration propagation normally takes.

Create a current database export and complete files backup, then verify they can be read.
Save the old PHP version, loaded extensions, relevant limits, handler, and custom INI values.
Take a host snapshot when available, but do not treat an untested snapshot as the only recovery plan.
Keep backups outside the server or account being changed.
For a store, membership site, or booking system, define how orders and submissions created after the backup will be protected.

Switching PHP does not normally require restoring the database. If production fails immediately, returning the PHP selector to the previous version is usually the narrowest rollback. Restore data only when a component changed it and the evidence justifies that larger action.

4. Build production-like staging before changing PHP

Clone the current code, database, configuration shape, PHP extensions, scheduled tasks, and representative data to a private staging environment. Block real customer email and payment capture while preserving safe test routes. A blank WordPress install proves only that core starts; it does not exercise your site’s plugin graph, content, traffic paths, or integrations.

Confirm staging is access-controlled and excluded from indexing.
Replace live payment, email, SMS, CRM, storage, and webhook credentials with sandbox values or explicit blocks.
Run a baseline acceptance test on the old PHP version first.
Update planned WordPress, plugin, and theme dependencies in a controlled order.
Switch only staging to PHP 8.3 and confirm both web and CLI runtimes.
Restart or reload the correct PHP service through the host workflow, then verify the effective configuration.

Use the same change discipline described in the site update checklist: version inventory, production-like staging, acceptance tests, a rollback boundary, and a recorded result. Do not combine a PHP migration with a redesign, cache-stack replacement, database cleanup, and multiple unrelated plugin swaps.

5. Log deprecations and fatals without printing them into responses

On staging, enable WordPress debugging long enough to exercise the site, but keep display off. Visible warnings can corrupt REST or AJAX JSON, feeds, file downloads, and headers even when the page appears usable.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Edit existing definitions instead of adding duplicates. Match PHP-FPM, web-server, application, and WordPress log entries to a recorded test time. Remove sensitive values before sharing excerpts. Restore the normal debug configuration after testing and remove any publicly reachable log copy.

Evidence after the switch	Likely cause	Narrow response
Parse error or fatal naming a plugin/theme file	Incompatible code or mixed package	Install its verified compatible release or roll back that component
`TypeError`, argument, or return-type failure	Stricter runtime exposes an invalid assumption	Fix the named code path; do not suppress the exception
Function or class missing	Extension, loader, dependency, or deployment is absent	Compare modules and complete the verified package
Warnings/deprecations but workflow completes	Technical debt that may become a future failure	Log, prioritize, update the owner, and keep display off
Web works; cron or CLI fails	Different PHP binary, INI, extension set, user, or path	Align the intended runtime and retest that execution context
Intermittent 502/504 after change	Pool crash, worker exhaustion, timeout, or extension fault	Inspect FPM/server logs and resource metrics before raising limits

Prioritize by impact: a deprecation in an unused admin screen is not equivalent to a fatal during checkout. Record both, but block deployment on failures in login, publishing, forms, payment, queues, scheduled tasks, backups, and other business-critical paths.

6. Test the workflows that execute different PHP paths

Loading the homepage once tests a narrow cached route. Run a written matrix on old PHP and PHP 8.3, using the same inputs where possible.

Public: uncached representative pages, search, feeds, 404, redirects, logged-out mobile, and an authenticated page.
Admin: login, edit and publish, media upload and image sizes, user permissions, plugin settings, and updates.
API: REST reads and writes, admin AJAX, application integrations, webhooks, and nonce-protected actions.
Forms and mail: validation, file upload, storage, spam controls, delivery, and notification templates.
Commerce: cart, taxes, shipping, sandbox payment, order email, stock, refund, subscription, and scheduled actions.
Background: WordPress cron, system cron, Action Scheduler or queues, imports, exports, backups, and cleanup tasks.
Command line: WP-CLI status, maintenance commands, deployment scripts, and Composer tasks that production actually runs.

Inspect new logs after each group and verify stored results, not just success banners. For example, confirm a scheduled event actually ran and the next recurrence remains correct; the WordPress cron backlog guide explains why a queue can look healthy while work remains delayed.

7. Repair the owner named by evidence

When a trace names third-party code, check its current compatibility statement and changelog. Update to a verified compatible release on staging, then repeat the failing action. If the current release is not compatible, choose a supported replacement, obtain a vendor fix, or delay the PHP change with a documented short deadline. Do not download unofficial “nulled” packages or edit a vendor plugin directly without an maintainable patch process.

A fatal line inside WordPress core does not automatically make core the cause; plugin input can surface deeper in the call stack. Follow the full trace and timing. If the site becomes unavailable, use the evidence-led WordPress critical-error recovery path rather than renaming every plugin at once.

Replace missing or mixed files with a complete trusted package.
Install only the extensions the application requires and the host supports.
Correct custom code against the PHP migration guides, then add a regression test.
Keep deprecations in a tracked backlog even when they do not block PHP 8.3.
Repeat the entire affected workflow and adjacent business path after every repair.

Too much complicated?

let me handle the hard parts so you don’t have to.

Prefer Fiverr? View my profile

8. Deploy PHP 8.3 with a canary, monitoring, and rollback owner

Choose a low-risk window with the host or engineer who can revert PHP.
Pause deployments and record the current code, database, PHP, extensions, and configuration.
Create the final backup and confirm recent business data is protected.
Change the production PHP branch through the host’s supported method.
Confirm the effective web and CLI versions before testing content.
Run a small health canary, then the written acceptance matrix.
Watch PHP, server, WAF, queue, payment, email, and application telemetry.
Keep the change open until delayed cron, webhook, and queue work has executed.

Do not expose a public OPcache reset script. Let the host reload the correct pool or use its authenticated control. Do not purge every cache before confirming PHP can render an uncached response; a warm page cache can hide a fatal at the origin.

Roll back without erasing useful evidence

If a critical path fails and cannot be repaired inside the agreed window, save the relevant logs and request IDs, then return the domain or pool to the recorded old PHP version. Verify the effective web, CLI, and cron runtimes; retest the failed workflow and confirm queued work recovers. Restore files or database only when a deployment or data write also requires it.

A rollback restores service, not compatibility. Open a follow-up with the exact failing component, version, trace, input, and PHP branch. Running indefinitely on PHP 7.4 is not an acceptable final state merely because it makes the error disappear.

Verify the PHP upgrade is complete

Site Health, a controlled web check, CLI, and scheduled jobs report the intended PHP branch.
The expected extensions and custom INI values are loaded in each runtime.
Fresh logged-out, logged-in, mobile, admin, REST, and business workflows pass.
New PHP/server logs contain no repeated fatal from the test matrix.
Cron, queues, webhooks, email, and payment callbacks complete after their normal delay.
Backups and monitoring still work under PHP 8.3.
Temporary debug settings, staging credentials, and maintenance controls are removed.

Success: WordPress, the web server, CLI, and schedulers use PHP 8.3 with the expected extensions; real workflows persist their results; no matching fatal returns in the observation window; delayed jobs complete; monitoring and backups remain healthy; and the documented PHP rollback is still available.

Keep the next PHP upgrade routine

Track PHP support dates, WordPress compatibility, and host availability quarterly.
Require current PHP compatibility evidence from custom and commercial component owners.
Keep staging close to production and run the acceptance matrix after dependency updates.
Alert on PHP fatals, 500-series responses, queue growth, failed cron, payment errors, and mail failures.
Remove abandoned plugins and duplicate functionality through controlled changes.
Document web, CLI, and scheduler runtimes so they cannot silently drift apart.

Official sources

Frequently asked questions

Can WordPress 7 run on PHP 7.4?

Yes. PHP 7.4 is the WordPress 7.0 core minimum, but the PHP branch is end of life and WordPress recommends PHP 8.3 or greater. Treat 7.4 as a temporary compatibility bridge while you test and repair the move to a supported branch.

Should I upgrade straight to PHP 8.5?

WordPress’s current matrix lists PHP 8.5 as compatible with WordPress 7 core, but your host, plugins, themes, custom code, and extensions must also pass. PHP 8.3 is the current WordPress recommended baseline; a newer target can be reasonable when the complete stack is explicitly tested.

Will PHP 8.3 make WordPress faster?

It can improve runtime efficiency compared with old PHP branches, but it cannot fix slow database queries, external API waits, oversized assets, too few PHP workers, or poor cache rules. Compare the same uncached and business requests before and after rather than promising a universal percentage.

What should I do if the site shows a fatal error after switching?

Preserve the fatal and timestamp, then use the host’s recorded selector to return to the old PHP branch if a critical workflow is down. Verify the rollback, reproduce the issue on staging, and update or repair the component named by the full trace.

Does changing PHP modify the WordPress database?

The server-level PHP switch itself does not migrate the database, but plugins and themes executing after the switch can run upgrades or write data. Take a database backup, record component updates separately, and prefer the PHP selector rollback before restoring data that may contain new orders or submissions.

Need help planning the PHP change?

For a production-safe PHP inventory, staging migration, business-workflow test matrix, evidence-led compatibility repair, and monitored deployment with rollback, see AbdullahWP WordPress services.