PHP 8.2 support ends 31 December 2026: what it means for your WordPress or Laravel site

Quick answer: PHP 8.2 stops receiving security fixes on 31 December 2026 — that’s PHP’s own stated date. After that, a site on 8.2 keeps running but no longer gets patches, so it’s a sitting target the next time a vulnerability turns up. Some hosts are removing 8.2 even earlier. If your WordPress, WooCommerce or Laravel site is on 8.2, the job for the next few weeks is to plan a move to 8.3 or 8.4 — and if it’s a Laravel app, to check the framework version too, because the two are linked.

Most end-of-life deadlines slide by unnoticed. This one is worth a calendar entry, because it lands right on the December holiday period — the worst possible time to be scrambling with a broken site and a skeleton support crew.

What’s actually happening on 31 December 2026

When PHP released the 8.2.35 security update in October 2026, the release note said it plainly: “PHP 8.2 reaches end of life on 31 December 2026 and will receive no further security fixes after that date. Please plan your upgrade to a supported version.”

That’s the whole event. Nothing breaks at midnight. Your site doesn’t go offline. What ends is the stream of security fixes — so from 1 January 2027, any newly discovered PHP vulnerability that affects 8.2 simply stays open on your site unless you’ve moved to a supported version.

If end-of-life dates are new to you, our guide to supported PHP versions has the full timeline and the “who’s responsible for patching” breakdown.

Some hosts are moving before December

The 31 December date is PHP’s. Individual hosts set their own, often earlier, because they don’t want to be running unsupported software on the day support ends.

As one published example, WP Cloud (Automattic’s hosting platform) announced it will remove PHP 8.2 on 15 December 2026 — a fortnight before PHP’s own cut-off. Other hosts will have their own dates, earlier or later. The practical lesson: don’t assume you have until 31 December. Ask your host what their date is, because theirs is the one that affects you first.

Who this affects

A meaningful slice of the web. WordPress.org’s PHP statistics (read October 2026) show roughly a quarter of reporting WordPress sites still on 8.2 — one of the single most common versions in use. So if you’re on 8.2, you’re far from alone, and that’s precisely why it’s worth acting early rather than joining a December rush.

The same stats show plenty of sites on 8.1 or older too. If that’s you, you’re already past end of life — the move is more urgent, not less, and the destination is the same.

Where to aim

For WordPress and WooCommerce, the target is straightforward. WordPress recommends PHP 8.3 or greater, and WooCommerce recommends 8.3 or greater as well (tested up to 8.4). So:

• 8.3 is the sensible, well-supported default — patched until the end of 2027.
• 8.4 is a fine choice too, and buys you longer — security fixes until the end of 2028.

Either gets you comfortably clear of the deadline. The move from 8.2 to 8.3 is usually a modest one, but it should still be tested on a staging copy first, because older plugins and themes are where surprises hide.

The Laravel trap worth knowing about

If your site is a custom Laravel application rather than WordPress, there’s an extra wrinkle: the Laravel framework version and the PHP version are coupled. Each Laravel release only supports a specific range of PHP versions.

From Laravel’s release documentation: Laravel 9 supports PHP 8.0 to 8.2, and its own security support ended back in February 2024. Here’s the deduction worth drawing from those two facts — and we’re flagging it as a deduction, not an official Laravel statement:

A Laravel 9 app can only run on PHP up to 8.2. Once PHP 8.2 reaches end of life on 31 December 2026, a Laravel 9 app can no longer run on any PHP version that PHP itself still supports — without first upgrading the framework.

In other words, for older Laravel apps the PHP deadline and a framework upgrade arrive together. That’s not a reason to panic, but it is a reason to start the conversation now rather than in December, because a framework upgrade is a project, not a setting. (Laravel 12, by contrast, supports PHP 8.2 to 8.5 with security fixes into 2027, so newer apps have more room.) We’ve set out the upgrade paths for older Laravel apps in a separate article.

How to plan the move

Work backwards from the deadline — and from your host’s earlier date, if they have one:

1. Confirm your current PHP version and your host’s cut-off date. These two numbers set your timeline.
2. Update plugins, themes or framework dependencies first. The software on top is the usual blocker, not PHP itself.
3. Test on a staging copy. Switch PHP there, exercise checkout, forms, logins and any integrations, and read the error log before you touch live.
4. Go live with a rollback ready, then re-check that the site genuinely reports the new version.
5. If the app is years behind, weigh a straight upgrade against a more substantial rebuild using our rewrite-versus-refactor framework before committing either way.

The one thing not to do is leave it until the week before Christmas.

If you’d like help working out which version you’re on, whether your plugins or framework are ready, and how much work the move actually is, that’s part of our web development work. Start a project or get in touch and we’ll scope it honestly — including telling you if it’s a quick job.

Common questions

What happens to my site on 1 January 2027 if it’s still on PHP 8.2? Nothing visible — it keeps running. What changes is that PHP stops issuing security fixes for 8.2, so any new vulnerability affecting that version stays unpatched on your site until you move to a supported one.

Should I upgrade to PHP 8.3 or 8.4? Both are supported and either is a good choice. 8.3 is the common recommendation and is patched until the end of 2027; 8.4 buys an extra year, with fixes until the end of 2028. For most sites the difference is marginal — the important thing is getting off 8.2.

I have a Laravel app. Is upgrading PHP enough? Not necessarily. Laravel ties its supported PHP versions to the framework version, so an older Laravel app (Laravel 9, for instance) may need a framework upgrade before it can run on a newer, supported PHP. Check the framework version alongside the PHP version.

My host says they’ll force the upgrade for me. Is that fine? It’s common, but a forced version switch can break an older plugin, theme or piece of custom code with no warning. If your host is going to move you automatically, find out the date and test your site on the new version beforehand so you’re not discovering problems live.