Security support for PHP 8.2 ends on 31/12/2026. From 01/01/2027 the PHP project will not patch any newly discovered vulnerability in it, and hosts are already scheduling its removal. For a WordPress website that is kept updated, this is a planned move to PHP 8.3 or 8.4, typically a short, scheduled round of testing. For a website that has not been maintained, it is the moment years of deferred updates come due at once.
End of life sounds like an event. It is not. It is a date that was published years in advance, and every website reaches it in one of two conditions: current enough that the upgrade is routine, or so far behind that the upgrade becomes a rebuild. The deadline does not decide which condition you are in. Your maintenance history already has.
PHP 8.2 is the clearest current example, so this article starts there. But PHP is only one layer of a WordPress website, and the same lifecycle logic applies to WordPress itself, the database, the server operating system and every plugin you depend on. Understanding how end of life works across that stack is the difference between a calm December and an emergency in February.
What End of Life Actually Means
PHP follows a fixed, published lifecycle. Each release branch gets roughly two years of active support, during which bugs and security issues are fixed and regular point releases ship, followed by two years of security-only support, where only critical security issues are patched on an as-needed basis. After that the branch is end of life. php.net’s own wording is blunt: users of unsupported versions are strongly urged to upgrade, because older versions may expose them to security vulnerabilities that have been fixed in more recent releases.
The current position, taken from php.net’s supported versions page:
- PHP 8.1: security support ended 31/12/2025. End of life.
- PHP 8.2: active support ended 31/12/2024. Security support ends 31/12/2026.
- PHP 8.3: security support until 31/12/2027.
- PHP 8.4: active support until 31/12/2026, security support until 31/12/2028.
- PHP 8.5: released 20/11/2025, security support until 31/12/2029.
PHP 8.6 is in release candidate testing, with general availability planned for 19/11/2026. It is not a production target for a business website this year. Brand new branches wait for the plugin ecosystem to catch up, which is exactly the lag that makes the older branches dangerous to sit on.
The important point is not the dates themselves. It is that PHP 8.2’s end of life has been on the calendar for a long time. It was originally due in December 2025, and the PHP project’s 2024 release cycle update extended security support and moved it to 31/12/2026. A business that reaches 31 December unprepared does not have a technical problem. It has a governance problem: nobody owned the question.
Why the Date Matters More Than It Appears To
A common response to end of life is “the website still works.” It does, on the day. PHP does not switch off at midnight on 31 December. What changes is everything around it.
Hosts remove the version
Managed hosting platforms follow the PHP lifecycle and retire versions on a schedule. WP Cloud, the infrastructure behind several large WordPress hosts, has published that PHP 8.2 will be removed from its platform on 15/12/2026. Locally, xneelo has published that PHP 8.2 will be permanently removed from its servers in December 2026, and scheduled automatic upgrades of websites still on 8.2 to PHP 8.3 ahead of that removal. When the host makes the move for you, a website that is not ready breaks on the host’s timetable rather than yours.
Or the host keeps it, which is worse
On cPanel servers, which in our experience are common across South African shared and reseller hosting, the picture is different. cPanel’s EasyApache 4 documentation says it follows the php.net timeline, and that packages for unsupported PHP versions remain on its mirrors and servers but receive no further updates. In practice, the version usually stays installed and selectable after it stops being patched, unless the server administrator removes it. On many setups, nothing in the hosting panel prompts the website owner that the PHP version they selected years ago is now frozen.
There is a commercial layer on top of this. CloudLinux supplies security-patched builds of end-of-life PHP, cPanel sells extended PHP support, powered by TuxCare, as a paid per-server add-on currently covering versions up to PHP 8.1, and some hosts charge customers for legacy versions. GoDaddy moved PHP 8.1 into paid extended support on 01/01/2026 and enrols plans automatically at renewal. HostAfrica treats older versions as legacy, patched for an additional fee.
Extended support has a legitimate use. It buys time for a genuinely complex migration. As a strategy it is a recurring fee for not doing maintenance, and it does not restore the thing that actually matters, which is compatibility with the software that runs on top of PHP.
The PHP Upgrade Is Rarely the Problem
WordPress core is not what breaks. WordPress publishes compatibility for a wide range of PHP versions, and in May 2026 the core team retired the “beta” label it had applied to newer PHP versions, documenting WordPress 6.9 and later as fully supporting PHP 8.5. WordPress 7.0 also raised the minimum supported PHP version to 7.4. The recommended version on wordpress.org is PHP 8.3 or greater.
Read that requirements page carefully, though. It says WordPress also works with PHP 7.4 and MySQL 5.5.5, and in the same breath warns that those versions have reached their official end of life and may expose a website to security vulnerabilities. Compatible and safe are two different words. WordPress will run on software that nobody is patching any more, and plenty of websites are doing exactly that.
What actually breaks during a PHP upgrade is the layer above core: themes and plugins written against older behaviour, abandoned plugins that were never updated for newer PHP, premium plugins whose licence lapsed so updates stopped arriving, and custom code a previous developer wrote once and never revisited. Each PHP release deprecates functions and behaviour, and major versions remove them. Deprecated code raises warnings that can flood logs or break page output, and code that depends on removed or changed behaviour fails outright, sometimes visibly, sometimes only on the checkout or the contact form submission that nobody tests until a customer complains.
This is why a maintained website barely notices the deadline. If its plugins have been updated as their developers released fixes, those developers have already done the PHP compatibility work. The upgrade becomes a test on staging, a switch, and a check of the critical paths. On a neglected website every one of those plugins is several versions behind, so the PHP upgrade drags a year or more of plugin upgrades along with it, all at once, with no way to tell which change broke what. We set out the broader case in Why Regular Website Maintenance is Crucial.
“A PHP upgrade does not create problems. It reveals the ones that maintenance would have solved one at a time.”
What You Actually Lose: The Update Path
The real cost of staying on old PHP is not the PHP vulnerabilities on their own. It is that the rest of your software slowly stops being offered to you.
WooCommerce is the clearest illustration. Its current server requirements recommend PHP 8.3 or greater. In September 2026 the WooCommerce team confirmed that WooCommerce 11.6, planned for February 2027, will require PHP 8.1 or newer, and noted that only critical fixes, rated CVSS 9 or higher, are backported to older release series. WordPress will not install a plugin update when the server does not meet the plugin’s declared PHP requirement, so from WooCommerce 11.6 onward a store still on PHP 7.4 or 8.0 stops receiving new WooCommerce releases, and stays on 11.5 with only critical fixes backported for a time. Nothing visibly fails. The store freezes on its last compatible release while everything around it moves on.
The same mechanism applies to every plugin that raises its minimum PHP version. The website keeps working, the dashboard shows fewer updates than it should, and the gap between what is installed and what is safe widens every month. By the time somebody forces the issue, the upgrade is no longer one version jump. It is a migration, and migrations are website development work rather than routine maintenance.
When an end-of-life branch meets a serious vulnerability
The 2024 PHP-CGI vulnerability, CVE-2024-4577, is a useful case study even though it affected only PHP on Windows, with the highest risk where Apache ran PHP in CGI mode. It was rated critical and added to the CISA Known Exploited Vulnerabilities catalogue. Fixes shipped for the supported branches in June 2024. The researchers who found it noted that PHP 8.0, 7 and 5 were end of life and would not be patched, so short of upgrading to a supported branch, the only option for those installations was a temporary workaround. That is what end of life means in practice: when the serious vulnerability arrives, there is no patch coming.
End of Life Runs Through the Whole Stack
PHP gets the attention because its dates are prominent. A WordPress website depends on at least five layers that each have their own lifecycle, and the quieter ones are often further behind.
WordPress itself
WordPress’s security team states that officially only the latest version of WordPress is supported. Security fixes are backported to older branches as a courtesy, currently as far back as 4.7, and that courtesy has already been withdrawn once: updates for versions 4.1 to 4.6 ceased in July 2025. The 7.1.3 release on 06/10/2026 fixed seven security issues, and on the releases page only the most recent version in the 7.1 series is described as safe to use and actively maintained.
The database
MySQL 8.0 reached the end of its extended support on 30/04/2026, and the community support window for MariaDB 10.6 ended on 06/07/2026. Both are still widely deployed, and both are still listed as acceptable minimums in common WordPress and WooCommerce requirement documents. A WordPress dashboard can show every update applied while the database underneath it is no longer being patched. Most business owners have never been told which database version their website runs on.
The server operating system
CentOS 7 reached end of life on 30/06/2024. cPanel blocks new installs and upgrades on it from version 112, and servers still on version 110 remain in cPanel’s extended lifecycle support until 01/01/2027. If your website sits on an older server that nobody has migrated, the hosting panel can look normal while the operating system beneath it has received no standard security updates since mid-2024, and even the control panel’s own extended support ends on 01/01/2027.
Plugins, which have no lifecycle at all
Plugins are the least predictable layer because they have no published end-of-life dates. A plugin simply stops being maintained. WordPress.org shows a warning when a plugin has not been tested with the latest three major WordPress releases, and closes plugins for reasons that include unresolved security issues, at which point the plugin page states that it is no longer available for download. A website with a closed plugin installed keeps running it. The responsibility for noticing sits with whoever maintains the website.
How Common Running End-of-Life Software Is
More common than most business owners would guess. A Censys internet scan published in July 2026 observed that more than 70% of the roughly 316,500 WordPress websites it could fingerprint were running outdated PHP, with PHP 7.4, end of life since November 2022, the single most common version at more than 20%. Only about 14% were on WordPress 7.0, the latest release at the time. The sample only includes websites that expose version information, so it is not a perfect picture of the whole ecosystem, but the direction is unambiguous.
The pattern behind those numbers is familiar to anyone who inherits websites. Version drift is rarely a decision. Nobody chooses to run PHP 7.4 in 2026. The website was built, the developer moved on or the retainer lapsed, and the hosting panel kept serving whatever was selected at launch. Our website teardown method shows how to check your own website for this kind of drift in an afternoon.
What Being Ready Actually Looks Like
Readiness for end of life is not a project you start in December. It is the side effect of a website that has been looked after. In practice, a website that will take the PHP 8.2 deadline in its stride has these properties:
- Its plugins and theme have been updated as releases arrived, so their developers’ compatibility work is already installed.
- It carries no abandoned or closed plugins, and anything not updated in a long time has been replaced or removed.
- Premium plugin licences are current, so updates actually arrive.
- Custom code has been reviewed against the target PHP version, not just the PHP version it was written for.
- There is a staging copy where the new PHP version can be switched on and tested before the live website moves.
- Somebody tests the paths that make money: the enquiry form, the checkout, the booking flow, the account login.
- There is a current backup and a known way back if something unexpected surfaces after the switch.
None of this is exotic. It is ordinary website maintenance done on a regular rhythm. The PHP upgrade then becomes one more scheduled task: test on staging, switch, verify, done. On a maintained estate the move off 8.2 is planned work, not an incident.
Checking where your own website stands
You do not need a developer to find out which PHP version your website runs. In the WordPress dashboard, open the Tools menu and choose the health check screen listed there, then its Info tab, and open the Server section. The PHP version is listed there. The Status tab on the same screen flags an older PHP version as a recommended improvement, and one that no longer receives security updates as a critical issue. If the answer is 8.2 or older, the conversation with whoever maintains your website needs to happen now, not in the last week of December when every host and developer is busy with the same deadline.
If nobody maintains your website, or you are not sure who has access to the hosting account, that is the first problem to solve. Our guide to recovering access when a developer has disappeared covers how to regain control of the hosting and domain before you attempt any upgrade.
The Real Lesson of End of Life
Every few months another piece of the stack reaches its date: a PHP branch, a database version, a server operating system, a WordPress release line, a plugin whose developer moved on. Treated individually, each one looks like an emergency. Treated as a system, they are the predictable rhythm of running software, and the rhythm is published years ahead.
That is the reframe worth holding on to. End of life is not a threat to a well-run website. It is an audit of how the website has been run. A website that has been updated as it went passes without anyone noticing. A website that has been left alone is far more likely to fail, and the failure has nothing to do with 31 December. The deadline is just when it becomes visible.
If you are not certain which side of that line your website is on, a short technical check will tell you.
Frequently Asked Questions
When does PHP 8.2 reach end of life?
PHP 8.2 security support ends on 31/12/2026, according to php.net. After that date the PHP project releases no further fixes for the 8.2 branch, including for newly discovered security vulnerabilities.
Will my WordPress website stop working when PHP 8.2 reaches end of life?
Not on the day. PHP does not switch off. The risks are that new vulnerabilities stay unpatched, that your host removes the version and moves your website to a newer one automatically, and that plugins gradually stop offering updates to websites on old PHP versions.
Which PHP version should a WordPress website use in 2026?
WordPress recommends PHP 8.3 or greater, and WooCommerce recommends PHP 8.3 or greater, tested up to 8.4. For most websites, moving from 8.2 to 8.3 or 8.4 is the sensible step, after testing on a staging copy. PHP 8.6 is too new for production use this year.
How do I check my website’s PHP version?
In the WordPress dashboard open the Tools menu and choose the health check screen listed there, then its Info tab, and open the Server section. The PHP version is listed there. Your hosting control panel will also show which version is selected for the domain.
Is paid extended PHP support a good alternative to upgrading?
It can buy time for a complex migration, but it is not a long-term answer. It keeps the PHP version patched, but plugins and WooCommerce still raise their minimum PHP requirements, so the website gradually stops receiving updates regardless.
Does end of life only apply to PHP?
No. WordPress versions, database servers such as MySQL and MariaDB, server operating systems and individual plugins all reach end of life. MySQL 8.0’s extended support ended on 30/04/2026, for example. A properly maintained website keeps every layer within its supported window.
Not Sure Where Your Website Stands?
Our WordPress website maintenance plans include updates, security monitoring and backups as standard, and you can get a quotation for bringing an older website up to a supported footing before the deadline.
Or reach out through our contact page.
