PHP 8.2 Support Ends Dec 31

PHP 8.2 is still getting security fixes. That window closes on 31 December 2026.

That is not a WordPress dashboard setting. It is a hosting deadline. The version of PHP that runs your site lives on the server. Updating a plugin, turning on auto-updates, or clicking “Update WordPress” does not change it.

This brief is about that hosting job: confirm what you are running, plan the upgrade, test the site, then change the runtime. WordPress core execution is a separate job. This one is the runtime underneath it.

What actually ends on December 31

PHP publishes a supported-versions schedule. On that schedule, PHP 8.2 is in security support until 31 December 2026. After that date, the PHP project no longer ships security releases for 8.2.

That does not mean your website shuts off at midnight. It means new PHP 8.2 security issues stop getting official patches. Your host can keep serving the old runtime. Attackers do not have to wait for a convenient maintenance window.

WordPress still runs on PHP 8.2 today. WordPress currently recommends PHP 8.3 or greater. Recommendation is not the same as the security-support calendar. The calendar is why this is a scheduled job instead of a someday project.

This is not a plugin click

The WordPress dashboard is where owners spend their time, so it is easy to assume every important change lives there.

PHP does not.

The runtime is selected in the hosting panel, the server configuration, or a host-managed image. A plugin update can change PHP code on the site. It cannot change the PHP engine that executes that code. If your host is still on 8.2 in January 2027, every plugin and theme on the site is running on an unsupported engine — including the ones you just updated.

That is why this deadline belongs with hosting and maintenance, not with the plugin-update loop. The plugin loop still matters. It is a different loop.

The upgrade job, in order

A PHP upgrade is a change with a rollback path. The sequence is boring on purpose.

1. Read the current runtime. In WordPress, Site Health reports the PHP version. Your host’s panel should show the same number. If those two disagree, stop and find out which one the site actually uses. Guessing here is how you “upgrade” a staging box and leave production alone.

2. Inventory what depends on it. Plugins, the theme, custom mu-plugins, and any WooCommerce or form add-ons. You do not need a compatibility matrix for the entire WordPress ecosystem. You need the list of this site. Anything that has not been updated in two years is a flag, not a trivia fact.

3. Pick the target version with the host, not a blog post. PHP 8.3 is the current WordPress recommendation. Your host may already offer 8.3 or 8.4. The right target is a version they support, that WordPress supports, and that you can roll back from. Do not jump because a changelog looks exciting.

4. Change it somewhere a mistake is cheap. Staging if you have it. A maintenance window if you do not. The first load after a PHP bump is when fatal errors show up — often on one admin screen or one checkout template, not the homepage.

5. Verify like a customer. Homepage, login, every form, cart or booking flow, and a sample of the pages that produce calls. Then check Site Health again and confirm the reported PHP version matches the plan.

6. Record the new runtime. Date, previous version, new version, who changed it, what was tested. Next year’s deadline is easier when this year’s change is written down.

None of that is a guarantee that every plugin will like the new version. It is the difference between an upgrade you can reverse and an upgrade you find out about from a customer.

What we are not promising

A PHP upgrade is not a speed project, a ranking project, or a security product. It does not replace plugin updates, backups, or a firewall. It does not make an abandoned plugin safe.

We are not going to invent a plugin-by-plugin compatibility matrix. Official sources name the deadline and the recommended runtime. Your site names the rest.

If nobody owns this job, the default plan is “leave 8.2 until something breaks.” That is a plan. It is just a bad one, and it gets worse after 31 December 2026.

What this means for your site

If you maintain the site yourself, ask the host two questions this month: what PHP version is in production, and what is the documented way to move it with a rollback. Put the change on a calendar before the holiday freeze, not during it.

If nobody owns the runtime, that is the actual risk. Website support and maintenance is the owner page for this work. If you want the contrast with “the host will handle it,” start with cheap hosting versus managed website care. To request a PHP upgrade plan, contact us.

The dashboard click updates a plugin. The hosting job updates the engine the plugin runs on. December 31 is the engine’s date.