PHP 8.2 Reaches End of Life on 31 December: How to Check Your Website and Upgrade Without Breaking It

PHP 8.2, the version a large number of business websites still run on, stops receiving security fixes on 31 December 2026. The PHP project said so in its own release notes in October: PHP 8.2 will receive no further security fixes after that date. If your site is on WordPress or WooCommerce, the version of PHP underneath it matters as much as the plugins on top.

We have just seen why. In October, two critical PHP vulnerabilities that let attackers run code on web servers were fixed in an emergency release, php2shell. Sites on a supported PHP version got a patch. From January, sites on 8.2 will not get the next one.

What "end of life" actually means

PHP gives each version two years of active support and then two years of security-only fixes. When that runs out, php.net's definition is plain: the release is no longer supported, and its users may be exposed to unpatched security vulnerabilities. The website keeps working. Nothing switches off on 1 January. It simply stops being repaired.

Source: php.net supported versions, checked 5 November 2026.

Step 1: find out which PHP your site runs

Two places, two minutes:

• Inside WordPress. Go to Tools, then Site Health. If PHP is out of date, WordPress lists it as a critical security issue. The Info tab, under Server, shows the exact version.
• In your hosting panel. Look for PHP Configuration or PHP Info. Most shared hosts let you see and change the version there.

Write down the full number, not just "8.2". And if you see 8.1, 8.0 or 7.4, you are not facing a deadline. You are already past it.

Step 2: pick the version to move to

The platforms themselves point in the same direction:

• WordPress.org recommends PHP 8.3 or greater, and its hosting handbook goes further: PHP 8.4 or later for production.
• WooCommerce lists PHP 8.3 or greater, tested up to 8.4, and has announced that WooCommerce 11.6, planned for February 2027, will require PHP 8.1 or newer.
• PHP 8.5 is marked compatible only from WordPress 6.9 onwards in the core compatibility table. Older WordPress installs should not jump straight to it.

Our recommendation for most business sites: PHP 8.4. It is supported until the end of 2028, it is what WordPress's hosting guidance recommends, and it is the newest version WooCommerce says it has tested. Choose 8.3 only if a plugin you cannot replace is not yet ready for 8.4, and treat that as a one-year reprieve, not a destination.

Step 3: what tends to break, and why

WordPress core is ready. The risk lives in old themes and plugins, especially ones nobody has updated in years. From PHP's own migration guides, these are the changes we see most often in older code. The selection is ours; the rules are PHP's:

• Dynamic properties, deprecated in 8.2. Old plugins that attach data to objects on the fly fill the error log with notices. Usually noise, but it shows the code has not been maintained.
• Implicitly nullable parameters, deprecated in 8.4. Code like function foo(Type $a = null) now raises a deprecation notice. Common in plugins written before 2020.
• CSV functions. In 8.4, relying on the default escape argument of fputcsv, fgetcsv and str_getcsv is deprecated. That matters for product import and export plugins.
• Stricter type checks in 8.3 and 8.4, where functions that used to accept the wrong kind of value quietly now throw an error. This is the kind that can stop a page from loading.

Deprecation notices are warnings, not failures. They tell you what will break on a future version. Errors are what take a checkout down, and those are what testing is for.

One tool you may find recommended online: the PHP Compatibility Checker plugin. Its own plugin page now says it is no longer actively maintained, and WordPress's own guidance warns it may miss items or flag false positives. Do not rely on it for PHP 8.3 and above.

Step 4: upgrade without gambling on the live site

This is the order we use when we do it for clients:

1. Back up first. Files and database, stored somewhere other than the server. WordPress's own guidance starts here too.
2. Update everything else first. WordPress, theme and every plugin, on the current PHP. Most compatibility fixes ship as ordinary plugin updates.
3. Remove what you do not use. Every deactivated plugin is still code on the server. Delete it rather than test it.
4. Test on a copy. Most hosts offer a staging site. Switch the copy to the new PHP and click through what makes you money. Not an official WordPress requirement, but a cheap insurance policy.
5. Switch the live site in a quiet hour, then test again: home page, a product, add to cart, checkout, contact form, admin login, and one order or enquiry email arriving.
6. Watch the error log for a week. Some problems only appear on a scheduled task or an unusual page.

Know how you will roll back before you start. On many hosts, switching PHP back is one click. On some, versions below 8.2 are no longer offered at all, which means an old site that breaks has nowhere to retreat to. That is the strongest argument for doing this in November rather than the last week of December.

If a plugin will not run on 8.3 or 8.4

You have three honest options: replace it with a maintained alternative, pay to have it fixed, or accept that the site depends on abandoned code and plan its replacement. What you should not do is stay on an unsupported PHP to keep one plugin alive. That trades a known fix for an open-ended risk to everything else on the server, including your customer data.

If the list of plugins that cannot move is long, the site may be telling you something bigger. We cover that decision in WordPress or a custom website, and the wider security checklist in our website security guide for UAE businesses.

Keeping PHP, WordPress and plugins current, tested and backed up is what our WordPress service is for, and when an upgrade becomes a rebuild, it is part of our web development work across the UAE and GCC. Send us the site and we will tell you which PHP it runs and what moving it involves.

Dates and requirements as published by the PHP project, WordPress.org and WooCommerce on 5 November 2026.