The short answer
PHP 7.4 stopped receiving official security fixes in November 2022, and no official PHP release fixes PHP2Shell on it (source: php.net unsupported branches; Beazley Security Labs). Move to PHP 8.4, which gets security fixes until December 31, 2028 (source: php.net supported versions). WordPress core is usually the easy part. What breaks is mostly old plugins, themes and custom code. To find it before your visitors do:
- update everything on a staging copy;
- read each plugin’s declared PHP support;
- scan the code with PHPCompatibility;
- switch the staging copy to 8.4 and test the pages that make you money.
Switch production only when staging is quiet, and keep a way back.
Why 7.4, and why now
PHP 7.4 is still common. Bitsight’s scans found it was the most common branch among PHP instances with an identifiable version, even though it got no official fixed release for PHP2Shell (source: Bitsight). WordPress shows the same lag. WordPress.org’s own statistics show that about a third of WordPress sites (34% as of October 24, 2026) run PHP older than 8.2, versions that no longer get official security fixes (source: WordPress.org statistics). WordPress itself is mostly up to date, thanks to automatic updates. The PHP version underneath is set by the hosting environment, and WordPress auto-updates don’t change it (source: WordPress.org version statistics).
If your host patched 7.4 with a backport, you may be patched for PHP2Shell and still sit on a branch that gets no official fixes (source: Beazley Security Labs; php.net unsupported branches). Many hosts and distributions ship fixes as backports that keep the old version number (source: AlmaLinux), so the version number won’t tell you either way. Treat a backport as a bridge with an end date, not a destination.
Why 8.4 and not 8.3
PHP 8.3 gets security fixes until December 31, 2027, PHP 8.4 until December 31, 2028, and PHP 8.5 until December 31, 2029 (source: php.net supported versions). Going to 8.3 means doing this again in about a year. Choose 8.5 if every plugin, theme and library you rely on supports it; otherwise choose 8.4.
What breaks, and where to look
Moving from 7.4 to 8.4 crosses five PHP releases at once: 8.0, 8.1, 8.2, 8.3 and 8.4. Each one changed or removed things. PHP’s own migration guides list the backward-incompatible changes for each: 8.0, 8.1, 8.2, 8.3 and 8.4. In a WordPress site, the problems show up in a few predictable places:
| Where | What goes wrong | How you’ll notice |
|---|---|---|
| Plugins that haven’t been updated in years | They call functions or rely on behaviour that PHP has since changed or removed | A fatal error (“critical error” screen) or a blank page when the plugin’s code runs |
| Themes, especially custom or child themes | Template code and functions.php snippets written for older PHP |
Broken layouts, errors on specific page types |
| Custom code | Must-use plugins, code-snippet plugins, cron scripts, import and export jobs | Failures in the background, often only in logs or missing emails |
| Libraries bundled inside plugins | A plugin can be current but still ship an old copy of a library | Errors that name a file inside the plugin’s vendor folder |
| PHP extensions | The new PHP build on your server may not include an extension your code needs | Errors about a missing class or function as soon as the feature is used |
| Deprecation notices | Code that still works but uses something PHP plans to remove | Warnings filling the error log. Fix them now; they tend to become errors in a later version |
How to check, step by step
1. Take an inventory
List the WordPress version and the PHP version that serves the site, not just the command-line version (source: AlmaLinux). Then list every plugin and theme with its version, plus must-use plugins and any custom code. Note anything that hasn’t been updated in a long time, and anything you no longer use. Removing an unused plugin is the cheapest compatibility fix there is.
2. Make a staging copy and update everything on it first
Copy the site to staging. Leave it on its current PHP version and update WordPress core, every plugin and every theme there. You want to test the code you’ll actually run, not last year’s versions. Check the WordPress PHP compatibility table for your WordPress release: WordPress PHP compatibility.
3. Read each plugin’s declared PHP support, and know its limits
Plugins and themes can declare a “Requires PHP” version. It’s a minimum: “Requires PHP: 7.4” means the author says the plugin needs at least 7.4. It doesn’t say the plugin works on 8.4. “Tested up to” refers to the WordPress version, not PHP. For each plugin, look for an explicit mention of PHP 8.x support in its changelog or support forum. Where you can’t find one, and the plugin hasn’t been updated recently, plan a replacement now.
4. Scan the code with PHPCompatibility
PHPCompatibility is a set of rules for PHP_CodeSniffer that checks code against the PHP versions you name. PHPCompatibilityWP is its variant for WordPress projects. A developer can run it against wp-content without touching the live site, for example:
vendor/bin/phpcs -p --standard=PHPCompatibilityWP --extensions=php \
--runtime-set testVersion 8.4 wp-content/plugins wp-content/themes wp-content/mu-plugins
Use 7.4-8.4 as the test version if the code must keep running on both while you move. Use a current release of PHPCompatibility, because older releases don’t know about newer PHP versions. A static scan finds a lot, but not everything. It can’t see code that’s built at runtime, and it can’t tell you whether a page still behaves correctly. That’s what the staging test is for.
5. Switch staging to PHP 8.4 and turn on logging
Switch the staging copy to PHP 8.4 in your control panel or server configuration, then restart PHP so the new version is actually running (source: AlmaLinux). Turn on WordPress’s debug log on staging only. When you’re done, turn it off and delete the log file: it can contain sensitive data and may be reachable from the web.
6. Test what matters
Walk through the pages and tasks that matter most to the business:
- checkout and payments;
- contact and quote forms;
- logins and account pages;
- search;
- uploads;
- the admin screens your team uses;
- scheduled jobs and outgoing emails.
Then read the error log. Fix or replace whatever breaks, and test again. Repeat until the log is quiet.
7. Switch production, and keep a way back
- Take a backup stored off the server, and confirm it restores.
- Agree how you’d switch back, and who decides.
- Pick a quiet time. Online stores should finish runtime changes before their holiday code freeze; Black Friday is November 27 and Cyber Monday November 30, 2026.
- After the switch, restart PHP, then confirm the version that serves the site changed (source: AlmaLinux).
- Re-check your security settings on the new version, including PHP’s recommended setting for CVE-2026-115560 (
session.upload_progress.enabled=0at server level). No PHP release fixes that flaw as of October 23, 2026 (source: php.net advisory on CVE-2026-115560, October 23, 2026). - Run your test list again on production, and watch the error log for a few days.
When to stop and get help
Stop and get a second opinion if:
- the scan flags hundreds of issues in custom code;
- a plugin your business depends on has no PHP 8.x support and no replacement;
- your host can’t run PHP 8.4 on your plan;
- checkout fails on staging and you can’t see why.
None of these are reasons to rewrite the site. Other technologies have had flaws just as severe (source: Google Cloud), and PHP 8.4 is supported until December 31, 2028 (source: php.net supported versions). They’re reasons to plan the work properly. The PHP 8.2 end-of-life checklist covers the project plan. Agencies moving many sites should use the agency triage guide to batch them.
Sourced facts
Full wording, primary sources and dates: /sources.
| ID | Fact | Primary source | Date |
|---|---|---|---|
| S-33 | 8.1 security fixes ended Dec 31, 2025; 7.4 in Nov 2022 | php.net EOL | Checked Oct 23, 2026 |
| S-03 | No official PHP2Shell fix for 8.1 and older | Beazley | Oct 21–23, 2026 |
| S-32b | 8.4 → Dec 31, 2028; 8.5 → Dec 31, 2029; 8.3 → Dec 31, 2027 | php.net supported versions | Checked Oct 23, 2026 |
| S-39 | Bitsight: 7.4 the most common branch among version-identifiable PHP instances | Bitsight | Oct 21, 2026 |
| S-35 | About a third of WordPress sites (34% as of Oct 24, 2026) below PHP 8.2 | WordPress.org stats | Oct 24, 2026 · LIVE |
| S-36 | WordPress core mostly current; PHP set by hosting | WordPress.org stats | Oct 23, 2026 |
| S-09 | Backports keep old version numbers; CLI may differ from web PHP; restart needed | AlmaLinux · Red Hat | Oct 21, 2026 |
| S-02b | CVE-2026-115560 interim setting | php.net | Oct 23, 2026 · LIVE |
| S-47 | Other stacks aren’t immune | Google GTIG | Dec 2025 |
Frequently asked questions
Can I jump straight from PHP 7.4 to 8.4, or should I go one version at a time?
On production, switch once, straight to the target. On staging, test the target version directly. Step through 8.0 to 8.3 only if you need to narrow down which change broke something. Each extra production switch is another chance for something to go wrong.
Does “Requires PHP: 7.4” mean a plugin works on PHP 8.4?
No. “Requires PHP” is the minimum version the author says the plugin needs. It says nothing about the newest version the plugin supports. Look for explicit PHP 8.x support in the changelog, then confirm it on staging.
Will updating WordPress move my site to PHP 8.4?
No. WordPress updates itself, but the PHP version is set by your hosting environment, and WordPress auto-updates don’t change it (source: WordPress.org version statistics). You, your developer or your host switches it. Questions to ask them.
Is a host backport of PHP 7.4 a reason to wait?
It buys time, not support. No official PHP release fixes PHP2Shell on 7.4; backports come from hosts, distributions or extended-support providers (source: Beazley Security Labs). Ask your provider in writing how long they’ll keep backporting, and finish the upgrade before then.
Find out before you book the work
- EOL Readiness Report. A read-only check of one site: an inventory, a compatibility scan of your theme, plugins and custom code against PHP 8.4, your plugin vendors’ declared support, and whether your host can run 8.4. You get a verdict (switch-ready, needs code changes, host can’t run 8.4, or bridge) and a fixed quote for the work. Nothing changes on your site. Ask for it