PHP end of life is the date the PHP project stops releasing security fixes for a version. Your website keeps loading after it, but the next flaw found in that version stays open for good. For PHP, the language behind WordPress and most other self-hosted websites, version 8.1 lost support on 31 December 2025, PHP 8.2 loses it on 31 December 2026, and 8.3 is covered until 31 December 2027. The same clock runs on your CMS, your server image and every plugin. Upgrade when one layer is expiring and the code around it is still maintained. Rebuild or migrate when several layers expire together or nobody maintains the code any more. This guide is from xCreative™, the Melbourne studio that builds websites and then hosts and maintains them. It follows our article on PHP2Shell, the October flaw that showed which sites were still on supported software.
What end of life means, and why the site still works
The PHP supported versions page sets out two stages. A branch first gets active support with regular bug fixes, then a period of security fixes only. After that it is end of life, and php.net warns that users of an unsupported release “may be exposed to unpatched security vulnerabilities”.
- PHP 8.1 and older: security fixes have ended. 8.1 lost support on 31 December 2025, and its last release was 8.1.34.
- PHP 8.2: security fixes until 31 December 2026.
- PHP 8.3: security fixes until 31 December 2027.
- PHP 8.4: security fixes until 31 December 2028.
- PHP 8.5: security fixes until 31 December 2029.
Dates from php.net’s unsupported branches list and supported versions page, checked on 5 November 2026. PHP2Shell showed what this means in practice: the PHP project shipped fixes for 8.2 and newer, and sites on 8.1 had to rely on a host or Linux vendor backporting the patch. Our guide to checking your website PHP version explains how to read the number and who patches it.
Our own servers run PHP 8.2.35 today, so the December 2026 deadline is ours as well. Moving them to PHP 8.3 is next on our list, and each site will be tested on 8.3 before it switches.
CMS versions with official end dates
PHP is one layer. The content management system has its own lifecycle, and the projects below publish theirs:
- Drupal. The Drupal core release schedule says Drupal 7 support ended on 5 January 2025 and Drupal 10 reaches end of life on 9 December 2026, the same week Drupal 12 is released. No new Drupal 10 releases will be made after that date.
- Joomla. Joomla’s 5.2.4 release announcement said Joomla 4 would only receive security updates until 14 October 2025. Sites still on Joomla 4 have had no security patches since.
- Adobe Commerce. Adobe’s lifecycle policy lists extended support for 2.4.5 ending on 11 August 2026 and for 2.4.6 on 31 August 2027. Version 2.4.7 has standard support until 31 May 2027.
- WordPress. WordPress does not publish end dates per version in the same way, so the practical test is its hosting requirements page, which currently recommends PHP 8.3 or greater.
Hosted builders such as Shopify or Wix run the platform for you, so there is no version for you to upgrade. What ages on those sites is the theme and any apps bolted on.
When the server image or hosting stack stops updating
A server image is the ready-made bundle of operating system and server software, PHP included, that a site is installed on. When the company packaging it stops, nothing visible changes. AWS’s notice on Lightsail blueprints packaged by Bitnami is a clear example. From 19 May 2026 no newer versions were released. The WordPress blueprint and three others are deprecated on 19 November 2026, and the Drupal and Magento blueprints, among others, follow on 19 May 2027. Existing instances keep running, and AWS states that owners remain responsible for applying updates and security patches.
We lived through this one. In October, 15 of the servers we manage ran that Bitnami stack on PHP 8.2.28, and the PHP2Shell fix could not be installed on them in place. Between 22 and 24 October we moved every one of them to new servers. AWS publishes a guide to migrating off Bitnami blueprints, and it notes there is no direct blueprint migration path for Joomla, Magento or Drupal, so those servers have to be set up again by hand.
Shared and managed hosts deal with expiring PHP differently, and some do not wait for you. WP Engine’s PHP guide says it removes end of life PHP versions from its servers and upgrades every site automatically, and that these upgrades cannot be deferred. That protects the server, but an old theme or plugin that cannot handle the newer PHP can break the day it happens. Keep your technical contact details current with your host, so the warning email reaches someone who can test the site first.
Plugins and themes their authors stop updating
WordPress.org flags this for you. Its plugin alerts documentation explains that a plugin which does not support the last three major WordPress releases shows a yellow notice, and a closed plugin shows a red one and is no longer available for download.
The squeeze also works in reverse. Contact Form 7 from version 6.2 requires PHP 8.3 and WordPress 7.1, so sites on PHP 8.2, ours included, stay on 6.1.7 until PHP moves. Any future fix will only ship in the newer releases. Expiry in one layer quietly freezes the layers above it, which is why we check the whole stack, not one number.
Check your versions, then upgrade, rebuild or migrate
Start with four questions for your developer or host:
- Which PHP version does the website itself run, and when does that branch lose security support?
- Which CMS version is installed, and is it on the project’s supported list?
- What server image or hosting stack is underneath, and is its maker still releasing updates?
- Which plugins, themes or extensions have not been updated in the past year?
Upgrade in place when only one layer is expiring and everything around it is maintained, such as a WordPress site moving from PHP 8.2 to 8.3. Test a copy of the site on the new version first, then switch.
Rebuild or migrate when a major version jump is needed, the theme has been abandoned, the custom code has no owner, or the hosting stack has stopped updating. At that point an upgrade can cost nearly as much as a rebuild and still leave fragile code behind. A rebuild through our website design and development team, or a move to a maintained ecommerce build for an ageing store, resets every clock at once.
Rankings survive a move when the URLs are handled properly. Google’s site move documentation says to map each old URL to its new one, use server side permanent redirects such as 301s, avoid redirect chains and watch Search Console through the move. It also states that 301 redirects “don’t cause a loss in PageRank”. Keeping the same URLs is simpler still, because then nothing needs redirecting. Our checklist for rebranding without losing Google rankings covers the same ground, and our SEO and GEO work checks that Google and AI search tools pick up the new site.
We track these dates across every server we manage as part of our website maintenance work, and we also take over sites built elsewhere. If you are not sure which of your layers expire next, contact our Melbourne studio and we will check the full stack and tell you whether to upgrade or rebuild.
Frequently asked questions
Is my website unsafe the day PHP reaches end of life?
Not on that day. Nothing changes until a new flaw is found in that branch, and from then on there is no official fix. Some hosts and Linux vendors backport patches to older branches, so ask yours in writing what they cover and until when.
Will my host upgrade PHP for me?
Some will, on their own schedule. WP Engine, for example, says its end of life upgrades are automatic and cannot be deferred. On your own server or cloud instance nobody upgrades it unless you or your developer do.
Will rebuilding my website lose my Google rankings?
It should not if the move is planned. Keep the URLs where you can, redirect any that change with 301s to their closest match, and watch Search Console for errors in the weeks after launch.
Related reading: What does website maintenance include? A checklist to compare providers
