PHP 8.2 End of Life and What Happens When Support Ends

PHP 8.2 reaches end of life on 31 December 2026, which means the PHP project will stop publishing security fixes for it after that date. For any business planning PHP 8.2 upgrades for UK businesses, that leaves just over three months from late September to test, fix and switch. Websites will not go offline on New Year’s Day, but they will be running software that nobody is patching any more.

The dates are set out on the PHP project’s own supported versions page. Active support for 8.2 ended on 31 December 2024, so the branch has already spent most of 2026 receiving security fixes only. The sections below cover what end of life means in practice, what keeps working, which version to move to and a realistic timetable to the deadline.

What End of Life Means for PHP 8.2

End of life means the PHP project no longer maintains the 8.2 branch in any form. Each PHP branch gets two years of active support, with bug and security fixes in regular releases, followed by two years of security fixes only. After those four years the branch is closed and appears on the list of unsupported branches, alongside PHP 8.1, which reached end of life on 31 December 2025.

For PHP 8.2 the four years run from its release on 8 December 2022. The timeline below shows where the branch sits as of 22 September 2026, including the date one major host has chosen to remove it ahead of the official deadline.

During the security only phase, releases come out as needed rather than on a fixed schedule. That matters because it means a security flaw found in January 2027 will be fixed in 8.3, 8.4 and 8.5, but there will be no corresponding 8.2 release to install. The post on what happens if a website runs an end of life PHP version covers the wider effects.

Is PHP 8.2 Still Supported

Yes, PHP 8.2 is still supported until 31 December 2026, but for security fixes only. The PHP.Watch status page for 8.2 lists it as receiving security fixes only, which has been the case since active support ended at the end of 2024.

Bugs that are not security issues have not been fixed in 8.2 for most of the last two years. A website on 8.2 today is on a version that has been in its final phase for some time. The remaining three months are the last window in which an upgrade can be scheduled before support runs out completely.

What Stops Working and What Does Not

Nothing stops working on 1 January 2027 by itself. PHP is software installed on a server, so an installed copy of 8.2 will keep running WordPress, WooCommerce and custom applications exactly as it did the day before.

The changes are gradual and come from around the website rather than from inside it. The main ones are listed below.

• New security vulnerabilities in PHP will not be fixed for 8.2, so any flaw found after the deadline stays open on websites that have not upgraded.
• Hosting providers will retire 8.2 on their own schedules, which can mean an automatic version change on a date the business did not choose.
• Plugin and theme developers will begin raising their minimum PHP version, so updates will stop installing on 8.2 over time.
• Security certifications and supplier questionnaires become harder to answer when a core part of the website is unsupported.

The certification point is worth planning for. Cyber Essentials requires critical and high risk security updates to be applied within 14 days, as IASME explains in its guidance. An end of life PHP branch has no updates to apply. The wider risks of staying on an unsupported version are covered in more detail in the guide to WordPress update problems, since PHP changes are one of the most common causes.

Which PHP Version to Move To

PHP 8.3 is the minimum version to move to, while PHP 8.4 is the better choice where the website’s plugins and code support it. WordPress itself lists PHP 8.3 or greater as its recommended requirement. The same page notes that older versions still run but have reached end of life and may expose a website to vulnerabilities.

The difference between the two is runway. PHP 8.3 has security support until 31 December 2027, so moving to it now means repeating the exercise in a little over a year. PHP 8.4 runs until 31 December 2028 and PHP 8.5 until 31 December 2029, according to the same php.net schedule. The language itself is not going anywhere either, as the earlier post asking whether PHP is still relevant for business websites sets out, so a move to a newer branch is an investment in a platform with a long future.

PHP 8.5 is the newest stable branch, but plugin support for it is still catching up, so it suits websites with little third party code. PHP 8.6 is scheduled for general availability on 19 November 2026 according to the PHP 8.6 release plan, which is too close to the deadline to be a sensible target for a business website this year. The guide to what is changing in PHP 8.6 covers when to move to it.

WordPress core is tested against all of these branches. The WordPress core compatibility table shows current releases supporting PHP 8.3, 8.4 and 8.5, so the version a WordPress website can run is decided by its plugins and theme, not by WordPress. The article on WordPress and PHP compatibility explains how to check each one.

Paying a third party for extended support of 8.2 is another option some businesses consider. It can keep security patches coming for a while, but plugin and theme developers will still move on, so it delays the upgrade rather than replacing it.

What Changes Between PHP 8.2 and the Newer Versions

Moving from 8.2 to 8.3 or 8.4 involves a small number of breaking changes and a longer list of deprecations. The official migration guide from PHP 8.2 to 8.3 lists the backward incompatible changes, most of which affect edge cases rather than everyday code.

Deprecations matter more for older plugins. PHP 8.2 itself deprecated dynamic class properties. Code that ignored those notices on 8.2 will still produce them on 8.3. PHP 8.4 adds further deprecations, including the implicitly nullable parameter types that are common in older WordPress plugins. Deprecation notices do not break a website on their own, but they fill error logs and signal code that will fail in a future major version.

The most common failures in practice come from abandoned plugins and from custom theme code written several PHP versions ago. Those are found by testing on a copy of the website, not by reading changelogs, which is why the timetable below puts staging work first.

Site Health also lists the active plugins and theme, which gives the starting inventory for the audit. Hosting control panels show the same PHP version and are the place to change it once testing is complete.

How Hosting Providers Handle End of Life Branches

Hosting providers do not all wait for 31 December. Some remove 8.2 earlier to avoid upgrading every customer during the busiest weeks of the year. Acquia is the clearest example, having published a PHP 8.2 end of life notice that sets 1 October 2026 as the date it ends support on its platform.

From that date Acquia removes PHP 8.2 and moves remaining environments to PHP 8.4, while applications already on 8.3 or newer are left alone. The notice gives the reasoning plainly, citing high traffic periods at the end of the year and the need to finish managed upgrades well before the PHP project’s deadline.

Other hosts take different approaches. Some move accounts to a newer version automatically, some leave 8.2 selectable with a warning and some charge for extended support of older branches. Any business on shared or managed hosting should check its provider’s notices now, because an automatic switch to 8.4 on a website that has not been tested is the scenario most likely to cause a fault at short notice. Hosts have a lot of accounts to move, given how much of the internet runs on PHP.

A Practical Timetable to 31 December

Roughly three months is enough time for most websites, provided the work starts in October rather than December. The plan below splits the remaining weeks into four stages, leaving December as a buffer rather than the working month.

Ecommerce websites should aim to finish stage four before the late November trading peak rather than during it. Where testing shows a plugin with no compatible version, the choice is between replacing it, commissioning a fix or rebuilding the feature. Each of those takes longer than the upgrade itself.

Websites with bespoke PHP code need extra time at stage three. Custom integrations with CRM, finance or booking systems are rarely covered by plugin updates, so any fixes have to be written and tested by a developer. Businesses weighing up a rebuild instead can compare PHP, Python and Next.js for a business website.

Getting the Upgrade Done Before the Deadline

The upgrade is done when the live website runs a supported branch with clean error logs and every critical journey has been tested. For most WordPress websites that means PHP 8.3 at a minimum or PHP 8.4 where plugin support allows, giving at least an extra year before the next upgrade is due.

PHP version upgrades sit inside the Priority Pixels WordPress support retainer, alongside managed UK hosting, uptime monitoring and security hardening. With 8.3 reaching end of life at the end of 2027, the same exercise will come round again soon. A website that is kept current is far quicker to move each time.