PHP 8.2 end of life: what WordPress and WooCommerce owners should check

By Fizz Labs · Updated 11 November 2026

If your host has sent a notice about PHP 8.2, or Site Health shows that your PHP version is getting old, this page explains what the date means and what to check before your site moves to PHP 8.3 or 8.4. It sticks to published facts and plain steps you can follow yourself.

The dates

The PHP project publishes the support period of every version on its supported versions page. Checked on 11 November 2026 (source: php.net supported versions):

The table on php.net can change. If you read this later, check the source page for the current dates.

What "end of life" means

Each PHP version first gets active support, with regular bug fixes, and then a period of security support, when only security issues are fixed. When security support ends, the PHP project stops releasing fixes for that version, including fixes for security issues found later. That is the whole meaning of the date.

Your site does not switch off on 31 December 2026. Nothing in WordPress reads that date. What changes is that a site still on PHP 8.2 after that day runs on a version that no longer receives security fixes from the PHP project. Hosts move customers to newer PHP versions on their own schedules and announce it in their own notices, so the date that matters for your site is the one in your host's notice.

How to find your PHP version

In the WordPress admin, open Tools › Site Health › Info and expand the Server section. The PHP version is listed there. Site Health may also show a notice on its Status tab when the version is getting old.

You can also look in your hosting control panel. Most panels have a PHP version or PHP settings page per site or per domain. That page is usually also where you switch the version, and many panels let you set it per site, so you can switch a staging copy first.

Write down the current version and the version your host plans to move you to. You will need both for the checks below.

A checklist for WordPress and WooCommerce

The same ten steps as on the home page, with a little more detail:

1. Find your current PHP version: Tools › Site Health › Info › Server.
2. Read your host's notice: when will they move PHP 8.2 sites, and to which version? If the notice is not clear, ask your host's support team.
3. List your plugins and themes, and mark which ones are custom code. Custom code is anything written for your site alone: a child theme with changes, a site-specific plugin, or code a developer added. Nobody else will update it for you.
4. Update plugins, themes and WordPress core to their latest versions first. Newer releases often include PHP compatibility fixes.
5. Check each plugin's page or changelog for PHP 8.3 or 8.4 support. If a plugin has not been updated for a long time, plan a replacement.
6. Make a full backup and a staging copy of the site. Some hosts offer one-click staging. Keep the backup somewhere other than the server.
7. Switch only the staging copy to PHP 8.3 or 8.4 in your hosting panel.
8. Turn on the debug log on staging and test the pages that earn money. For WooCommerce stores, test the cart and order pages, your payment gateways, order emails and subscription renewals if you use them. Then test contact forms, other emails and the admin screens you use every week.
9. Fix or replace anything that shows errors or deprecation notices, then test again. Deprecation notices do not stop a page today, but they mark code that a later PHP version may reject.
10. Switch the live site at a quiet time, with a rollback plan ready: know where the PHP version setting is and how to restore the backup.

Typical PHP 8.x deprecations in plugin code

When you read the debug log on staging, three kinds of deprecation notices come up often in older plugin and theme code. Each one is listed in the PHP migration guides.

${var} inside strings (deprecated since PHP 8.2)

Writing a variable inside a string as "${name}" or "${expr}" is deprecated. The usual fix is "{$name}" or plain concatenation. See the PHP 8.2 deprecated features page.

Dynamic properties (deprecated since PHP 8.2)

Creating a property on an object of a class that does not declare it, for example $this->cache = [] when the class has no $cache property, is deprecated. The usual fix is to declare the property in the class. The same PHP 8.2 page describes it.

Implicitly nullable parameter types (deprecated in PHP 8.4)

A typed parameter with a default of null, such as function save(Order $order = null), is deprecated. The fix is to write the type as nullable: ?Order $order = null. See the PHP 8.4 deprecated features page.

These three are only examples. A full check looks at every file of every plugin and theme, which is where an automated scan helps.

Do it yourself or hand it over

Steps 3, 5 and 9 take the most time. If you prefer to hand them over, Fizz Labs runs a static check of the plugin and theme folders you send as a zip. Basic ($80) gives a PHP 8.3 and 8.4 pass/warn/fail table for up to 10 plugins and themes. Standard ($250) covers up to 30 and adds patch diffs for auto-fixable issues in your custom code and a re-check log. Premium ($600) adds manual fix diffs for 1 custom plugin or theme and a host upgrade checklist. We never ask for passwords, admin access, FTP, SSH or database dumps, and we do not change your server. Static checks cannot see every runtime problem, so you still test on staging.

Email us for a quote. We reply with scope and price before any work or payment.

Ask for a fixed-price quote Compare the three packages

Disclosure: automated scan + AI-assisted fixes, automated checks before delivery.