What end of life means for PHP
PHP is the programming language WordPress runs on. The site's hosting decides which version it uses. Each version gets two years of active support, with bug and security fixes, then two years of security support, with security fixes only. After that, it gets nothing.
The dates, from PHP’s support schedule:
- PHP 8.1: security fixes ended on 31 December 2025.
- PHP 8.2: released December 2022; security fixes end on 31 December 2026.
- PHP 8.3: security fixes to the end of 2027.
- PHP 8.4: security fixes to the end of 2028.
- PHP 8.5: security fixes to the end of 2029.
A move to 8.4 or 8.5 buys the most time. A move to 8.3 is the smallest step from 8.2, and it is the minimum WordPress.org recommends to hosts. WordPress still runs on PHP 7.4, so WordPress will not stop a site on an old version. The date has to.
What we found on our own hosting
On 24 October 2026 we counted the live sites on one of the hosting platforms we run: 48 in all. Thirteen were on PHP 8.2, and one was still on 8.1, which had already lost its security fixes. Most sites had moved on, but nearly a third had not. A separate check on 25 October 2026 counted every site on that platform, staging copies included: 62 ran PHP 8.5 and two ran 8.4.
A version stays in place because a site works, and nobody is asked to change something that works. The end-of-life date has to be somebody's job.
What breaks, and how to find out first
Each new PHP version removes or changes things that older code relied on. A plugin or theme written years ago can stop working, or show errors on some pages and not others. In 2023, both TwinsUK sites we looked after needed repairs before they could run on PHP 8.1.
Compatibility makes the deadline a delivery decision. The version number is only part of the work. A site also depends on its theme, plugins and the tasks people need to complete. Testing a copy gives those dependencies room to fail before visitors encounter the change.
A successful version switch does not establish that every task still works. A page can load while its form or checkout fails. Verification needs to follow the site's purpose, with someone responsible for acting on the result.
Ownership continues after the switch
A test copy reduces uncertainty before a change. A recovery plan addresses what happens if the live change fails. Neither removes the need to check the result on the running site.
That continuing responsibility is part of our WordPress support. The TwinsUK work included compatibility repairs years after the original builds, as the software underneath them changed.
A site can keep working while the support beneath it expires. The deadline belongs in the maintenance plan before it appears as an urgent repair.
