PHP 7.4 stopped receiving security patches on 28 November 2022. That’s not a typo — it’s been unsupported for nearly four years, and according to Metorik’s 2026 analysis of 6,000+ WooCommerce stores, around 12% of stores are still running it. If your site is one of them, every vulnerability discovered in PHP since late 2022 has gone unpatched on your server. Nobody’s coming to fix it. Here’s what that actually means, and why PHP 8.4 is where you want to land.
What “End of Life” Actually Means
PHP versions get roughly two years of active support (bug fixes and security patches), followed by a further year of security-only patches, then nothing. Once a version is end-of-life, the PHP project stops looking for vulnerabilities in it, stops fixing the ones that get reported, and stops issuing advisories. The version doesn’t get worse — but the list of known, public, unpatched holes in it only grows.
Here’s where every recent version currently sits:
| Version | End of Life | Status |
|---|---|---|
| PHP 7.4 | 28 Nov 2022 | Fully unsupported |
| PHP 8.0 | 26 Nov 2023 | Fully unsupported |
| PHP 8.1 | 31 Dec 2025 | Fully unsupported |
| PHP 8.2 | 31 Dec 2026 | Security fixes only |
| PHP 8.3 | 31 Dec 2027 | Security fixes only |
| PHP 8.4 | 31 Dec 2028 | Actively supported |
If you’re on 7.4, 8.0, or 8.1, you’re not running old software — you’re running software that will never be patched again, connected to the internet, often processing customer data or payments.
Why This Is More Urgent Than It Sounds
It’s a live security hole, not a theoretical one. Every vulnerability disclosed publicly for PHP since 2022 is now a documented, searchable attack path for anyone running 7.4. Attackers specifically scan for outdated PHP fingerprints because they know the exploit will still work.
WordPress itself is moving past you. WordPress core still lists PHP 7.4 as its bare minimum, but its own documentation recommends running the latest stable version, and plugin and theme authors are increasingly testing and building against PHP 8.x only. Support tickets that start with “what PHP version are you on?” and end with “we can’t help until you upgrade” are becoming the norm, not the exception.
Your host may force the issue anyway. Most reputable hosts have already dropped 7.4 and 8.0 from their control panels, or are winding down support for 8.1 now that it’s EOL too. If you haven’t upgraded voluntarily, you may get an email one day telling you it’s happening automatically — usually with far less testing than you’d want.
If you take payments, this is a compliance problem, not just a technical one. PCI DSS requires that systems processing card data be kept current with security patches. Running an EOL PHP version on a checkout flow is very hard to justify to an auditor, or to a customer, if something goes wrong.
So Why PHP 8.4 Specifically, Not Just “Newer”?
You could technically jump to PHP 8.1, 8.2, or 8.3 and tick the “supported” box for now. But look at that table again — 8.1 is already dead, and 8.2 has a year left. Migrating is genuinely disruptive work: testing plugins, catching deprecated code, checking custom functionality. It’s not something you want to do every twelve months.
PHP 8.4 (released November 2024) gives you support through to the end of 2028 — the longest runway currently available. A few other things it brings to the table:
A meaningfully more efficient engine. Since PHP 7.4, the language has picked up a proper JIT compiler and several rounds of memory and opcode-cache improvements. To be straight about it: for a typical WordPress page load, the difference between PHP 8.3 and 8.4 alone is small — most of that hardware-level headroom was already banked in the jump to PHP 8.0-8.2. But cumulatively, 7.4 to 8.4 is a real, measurable step down in server resource usage under load, which matters if you’re on shared or budget hosting and traffic spikes.
Cleaner error handling. PHP 8.x surfaces type errors and mismatches as proper exceptions instead of silent warnings buried in a log file nobody reads. That means broken functionality on your site is far more likely to get caught and fixed early, rather than quietly degrading the experience for visitors.
A three-year head start before you have to think about this again. Upgrade once, properly, to 8.4, and you’re not back here doing this exercise again until 2028.
What Actually Breaks When You Upgrade (and Why You Test First)
This is the part agencies don’t always mention: jumping from 7.4 straight to 8.4 skips six years of accumulated changes, and some of it isn’t backward compatible. Common casualties:
- Old or abandoned plugins using functions or syntax removed in PHP 8.x (dynamic property creation, certain string/array function signatures)
- Custom theme code or old customisations written against PHP 7-era conventions
- Third-party integrations (payment gateways, shipping calculators, booking tools) that haven’t been updated in years
None of this is a reason to avoid upgrading — it’s the reason you don’t just flip the PHP version in your hosting panel on a Friday afternoon and hope. A proper upgrade path means testing on a staging copy first, checking the error log for deprecation warnings, and confirming every plugin and custom feature still works before it goes anywhere near your live site.
The Bottom Line
Running PHP 7.4 in 2026 isn’t “a bit behind” — it’s four years of unpatched security holes sitting on a server that’s almost certainly public-facing. PHP 8.4 gets you current, faster under load, easier to debug, and covered until 2028 instead of scrambling again next year. The upgrade itself is the easy part with the right process. Figuring out what will break on your specific site — old plugins, custom code, integrations nobody’s touched since 2019 — is where it actually gets done properly.
If you’re not sure what PHP version your site’s even running, or you know it’s overdue and want it handled without breaking anything, it’s worth a conversation.
Frequently Asked Questions
How do I check what PHP version my site is running? Most hosting control panels show it under a “PHP” or “Software” section. In WordPress specifically, you can check under Tools → Site Health → Info → Server, which also flags if your version is outdated or unsupported.
Will upgrading to PHP 8.4 break my website? It can, if your site relies on old, abandoned plugins or custom code that hasn’t been updated in years. That’s why upgrades should always go through a staging environment first — test everything, fix what breaks, then move it live.
Can I skip straight from PHP 7.4 to 8.4, or do I need to go version by version? You can jump straight there. There’s no technical requirement to step through 8.0, 8.1, 8.2, and 8.3 individually — you just want thorough testing beforehand, since you’re absorbing several versions’ worth of changes at once.
Is PHP 8.4 actually faster, or is that overstated? It’s genuinely more efficient than 7.4, particularly under load and on memory usage — but most of that gap opened up in the earlier 7.4-to-8.0 jump. Don’t expect your site to suddenly feel dramatically snappier from the PHP version alone; the bigger win is security and support, not raw speed.
What happens if I just… don’t upgrade? Your site keeps working, right up until a plugin update requires a newer PHP version, your host forces a migration, or a known vulnerability in 7.4 gets exploited. None of those happen on a schedule you control.
Does this affect WooCommerce stores specifically? Yes, more so — a checkout flow processing card data on an unpatched PHP version is a bigger compliance and security exposure than a brochure site. WooCommerce also drops support for old PHP versions faster than WordPress core does.
