PHP 8.2 end of life: what WordPress site owners need to do before 2027

PHP 8.2 end of life is 31 December 2026. After that date the PHP project stops releasing security fixes for it. On 14 October 2026, WordPress.org’s own statistics showed about 24 % of WordPress sites running PHP 8.2 and a further 37 % on versions that are already out of support, so roughly 61 % of WordPress sites will be on a PHP version the PHP project no longer supports on 1 January 2027 unless something changes. The fix is to move the site to PHP 8.3 or, better, 8.4. On a small, well-kept site that is a few hours of work, as long as it is tested on a copy first.

This guide explains what the date means, how to check what your own site runs, which version to move to, what tends to break, and what the job costs. Apart from our own time and cost estimates, every date and figure below comes from the organisation that publishes it; the sources are listed at the end.

What PHP 8.2 end of life means

PHP is the programming language WordPress is written in. It runs on your hosting, not in WordPress itself, which is why WordPress updates do not change it. Each PHP version is looked after for a fixed period. The PHP project describes three stages:

• Active support: “Reported bugs and security issues are fixed and regular point releases are made.”
• Security fixes only: “A release that is supported for critical security issues only.”
• End of life: “A release that is no longer supported. Users of this release should upgrade as soon as possible, as they may be exposed to unpatched security vulnerabilities.”

PHP 8.2 left active support on 31 December 2024 and has been in the “security fixes only” stage since. On 31 December 2026 it reaches end of life. These are the dates for every version a WordPress site is likely to be running today:

How many WordPress sites are affected

WordPress.org publishes the share of WordPress sites on each PHP version. We read those figures on 14 October 2026 and added them up:

• PHP 8.2: 24.0 % of sites. Supported today, out of support on 31 December 2026.
• PHP 8.1 and older: 36.9 % of sites, already out of support. PHP 7.4 alone, which stopped receiving fixes in November 2022, still runs 16.3 % of sites.
• PHP 8.3 and newer: 39.1 % of sites, on a version that will still be supported in 2027.

So about six WordPress sites in ten need a PHP upgrade to be on a supported version next year. WordPress.org does not publish how the figures are collected; they reflect WordPress sites that contact WordPress.org, not every site in the world, and they change over time. But the picture is clear: a large share of sites are still on a PHP version nobody has reviewed in years.

What happens on 1 January 2027

Nothing visible. Your site will not go offline at midnight. The change is quieter than that, and it builds up over the following months:

• Security holes stop being fixed. When a flaw is found in PHP 8.2 after the end of December, there will be no official fix for it. The site carries on working and, unless your host patches PHP itself, carries on exposed.
• Plugins move on. WooCommerce already recommends “PHP version 8.3 or greater”, although it still runs on older versions. As plugin authors raise their minimum PHP version, WordPress stops offering you their updates, so the site stays on an old plugin release and misses its security fixes.
• WordPress recommends newer. WordPress.org recommends “PHP version 8.3 or greater” and says of the legacy versions it still runs on that they “have reached their official End Of Life and may expose your site to security vulnerabilities”.
• Your host may decide for you. Some hosting companies remove old PHP versions or move sites to a newer one on their own timetable. If that happens before the site has been tested, the first you hear of it may be a customer telling you the site is showing an error. Ask your host what its policy is.

The UK’s National Cyber Security Centre is blunt about software that no longer gets updates. Its guidance on obsolete products says: “The only fully effective way to mitigate this risk is to stop using the obsolete product.” That guidance is written for organisations managing devices and software in general, not websites in particular, but the principle is the same for a site that takes payments, holds customer accounts or collects personal details.

How to check which PHP version your site runs

You can find out in two minutes, without touching anything:

1. Log in to WordPress and go to Tools → Site Health.
2. Open the Info tab and expand the Server section.
3. Read the line PHP version. The first two numbers are what matter: 8.2.x, 8.3.x and so on.

Your hosting control panel shows the same thing, usually under a heading such as “PHP settings” or “PHP version”, and it is also where the version is changed. If you see 8.3 or higher, you have at least a year in hand. If you see 8.2, you have until the end of December. If you see 8.1, 8.0 or 7.4, you are already past the date and should plan the upgrade now.

Which version to move to: 8.3, 8.4 or 8.5

The newest version is not automatically the right one. What matters is what your WordPress version and your plugins have been tested on. WordPress core publishes which PHP versions each release supports:

The WordPress core team acknowledges something worth repeating: WordPress “is rarely used in isolation (without any theme or plugins)”. Core supporting a PHP version does not mean your theme and your twenty plugins do. That is the whole reason the upgrade needs testing. WooCommerce, for example, lists itself as tested up to PHP 8.4, which is one more reason we move shops to 8.4 and not 8.5.

What usually breaks

How much work the upgrade is depends on where you start. From 8.2 to 8.3 or 8.4 the changes are small. From 7.4 the jump is bigger, because PHP 8.0 removed and tightened a number of things at once. These are the causes we see most, with the change in PHP that is behind each one:

• Old plugins that call functions PHP no longer has. PHP 8.0 removed several long-deprecated functions, among them create_function() and each(). A plugin that still uses one stops the page with a fatal error.
• Code that relied on loose comparisons. PHP 8.0 changed how a number is compared with a piece of text. Code written years ago can quietly start giving a different answer, which shows up as a filter that no longer filters or a price rule that no longer applies.
• Warnings in the error log. PHP 8.2 deprecated creating properties on the fly, and PHP 8.4 deprecated a common way of writing optional parameters. These do not stop the site, but on a badly configured server they can print messages on the page.
• Custom code nobody remembers. Snippets pasted into a theme’s functions file, or a bespoke plugin from a developer who has moved on, are the least tested code on the site and the most likely to fail.
• Abandoned themes and page builders. If the theme has had no update since 2020, it has never been tested on PHP 8; if it stopped a few years later, it has not been tested on the version you are moving to.

A site that is kept up to date, with a small number of maintained plugins, often goes through with no changes needed. A site with thirty plugins, some of them abandoned, needs someone to go through the error log line by line.

How to upgrade safely, step by step

Changing the PHP version is one click in most hosting panels. Do not start there. The safe order is:

1. Take a full backup of files and database, and check that it can be restored.
2. Update WordPress, the theme and every plugin on the current PHP version first. Many PHP problems are already fixed in newer plugin releases.
3. Remove plugins you do not use. Deactivated plugins still sit on the server and still count.
4. Make a copy of the site (a staging site). Many hosts offer this in the control panel.
5. Switch the copy to the new PHP version and turn on the error log.
6. Test what earns you money: every form, the login, the search, and on a shop a full order from basket to confirmation email.
7. Fix or replace whatever the log reports, then test again.
8. Switch the live site at a quiet time, repeat the tests, and keep an eye on the error log for a week.

If something goes wrong on the live site, you can normally switch back to the old version in the hosting panel while you sort it out. That is the reason to do this in October or November, with time to spare, and not in the last week of December, when developers and support desks are at their slowest.

How long it takes and what it costs

These are our own working estimates from doing this job, not quotes. Your site may take less or more, and we tell you before going over.

The sums: our WordPress development rate is £50 an hour + VAT and our e-commerce rate is £65 an hour + VAT. The smallest booking is 5 hours. A booking of 10 hours gets 5 % off and one of 15 hours gets 10 % off, so 10 WordPress hours are £475 + VAT, 10 e-commerce hours are £617.50 + VAT and 15 e-commerce hours are £877.50 + VAT. Hours you do not use never expire, so anything left over from a quick upgrade is there for the next change you need.

The button opens our book hours page with WordPress Development and 5 hours already selected. You pay by card, in full or with a 50 % deposit, and we get in touch to ask for access. If you run a shop, change the service to E-commerce Development before paying: a shop upgrade is booked at that rate because the checkout, the payments and the order emails all need testing. If you are not sure, ask us first and we will tell you how many hours to book.

If you cannot upgrade yet

Sometimes a site depends on one old plugin that has no replacement, and the upgrade has to wait for a rebuild. The NCSC accepts that this happens, and says that if you decide to continue at risk “in the short term, you should revisit this decision regularly”. In practice that means:

• Set a date for the upgrade or the rebuild, and put it in the diary.
• Keep WordPress, the theme and every other plugin fully up to date.
• Remove everything you do not need: unused plugins, old themes, old admin accounts.
• Put the site behind a web application firewall, and use strong, unique passwords with two-step sign-in for every administrator.
• Make sure backups run daily and are kept somewhere other than the web server.

None of this makes unsupported software safe. It lowers the odds while you fix the cause. Our guide to choosing hosting for a small business covers what a good host does for you here, and what a WordPress maintenance plan should include explains how to stop the site drifting out of date again.

After the upgrade: keep it from happening again

PHP versions end every December. PHP 8.3 follows on 31 December 2027 and 8.4 a year after that, so this is a job that comes round, not a one-off. Two habits make it painless: keep plugins few and current, so there is little to test, and have someone check the PHP version against its end date once a quarter. If you would rather not think about updates at all, our website care plans cover the monthly updates, backups and checks, and booked developer hours cover jobs like this one. A leaner, current site is usually a faster one too; see how to speed up WordPress.

Sources

All checked on 14 October 2026.

• PHP: Supported Versions (php.net): support dates for each PHP version and the definitions of active support, security fixes only and end of life.
• WordPress Statistics (WordPress.org): share of WordPress sites on each PHP version.
• WordPress Requirements (WordPress.org): recommended PHP version and the warning about end-of-life versions.
• PHP Compatibility and WordPress Versions (WordPress core handbook): which WordPress release supports which PHP version.
• WooCommerce Server Recommendations (WooCommerce): PHP version recommended and tested.
• Migrating from PHP 7.4 to 8.0, 8.1 to 8.2 and 8.3 to 8.4 (PHP manual): removed functions, comparison changes and deprecations.
• Obsolete products (National Cyber Security Centre): guidance on software that no longer receives updates.

Photo: Towfiqu barbhuiya via Unsplash