PHP 8.2 loses support on December 31. Which PHP version for WordPress in 2027

TL;DR

On December 31, 2026, PHP 8.2 receives its last security patch. PHP 8.1 hasn't received any since December 2025. If your site runs on either of these versions, you're entering 2027 on software where new holes will never be fixed, and since the 7.0 release WordPress.org officially recommends PHP 8.3 or newer. The sensible choice today is PHP 8.4, supported until the end of 2028 and compatible with the entire current plugin ecosystem. PHP 8.6 ships November 19, we cover it below, but don't put it on production yet. The rest of this article is the date table worth knowing, how to check your own version, and a safe upgrade path.

The timeline that should hang above your desk

PHP has a simple life cycle: every version gets two years of active support and two years of security fixes only. Then it ends, no exceptions, no extensions.

Version	Released	Security support ends	Status in September 2026
PHP 8.1	November 2021	December 31, 2025	dead, unpatched since December 2025
PHP 8.2	December 2022	December 31, 2026	final weeks of support
PHP 8.3	November 2023	December 31, 2027	security fixes only
PHP 8.4	November 2024	December 31, 2028	fully supported, recommended
PHP 8.5	November 2025	December 31, 2029	fully supported, young
PHP 8.6	November 19, 2026	December 31, 2030	RC since September 24, not for production yet

This table is enough to make the decision. Everything below PHP 8.3 is technical debt with compound interest.

What actually threatens a site on old PHP

The site won't stop working on January 1. It will keep running. The problem is elsewhere, and it grows quietly.

Holes that never get patched. When someone finds a vulnerability in the PHP interpreter after EOL, the fix ships for 8.3, 8.4 and 8.5. For 8.2 it never ships. Bots scanning the internet for old versions learn about it faster than you do. In practice a site on abandoned PHP is cheap to attack, and for a shop holding customer data that becomes a GDPR conversation, not just a technical one.

WordPress recommends newer versions, and the ecosystem follows. The official WordPress.org requirements list PHP 8.3 or newer as the recommended version. Core will technically still start on older PHP, but the recommendation defines what core and plugin authors actually test against. Historically WordPress raises its minimum version step by step and the oldest versions are always the ones dropped, so sitting on 8.1 or 8.2 puts you first in line. We covered the 7.0 release itself in a separate piece, and WordPress 7.2 ships in December, so the gap grows with every release.

Plugins move on without you. WooCommerce, Elementor and most serious plugins test new releases against PHP versions that are still supported. Authors drop compatibility with old versions quietly, usually in a single changelog line. On old PHP every plugin update is a lottery.

Performance left on the table. Every release from PHP 8.0 upward brings real interpreter and JIT gains. Moving a typical WooCommerce site from 8.1 to 8.4 usually means double-digit percentage faster TTFB for free, without touching a line of code. If you're fighting a slow site, start with a proper diagnosis, but bump the PHP version either way.

Which version to pick for 2027

PHP 8.4 is the best choice for most sites. Full support until the end of 2028, nearly two years of maturing in the ecosystem, and every plugin that matters declares compatibility. It's the version we set as default for our care plan clients.

PHP 8.3 is the acceptable minimum. If a plugin or an old theme won't run on 8.4, stepping down to 8.3 buys you time until the end of 2027. Treat it as a stopover, not a destination.

PHP 8.5 works fine, but you don't need it. A year on the market, stable, fast. If your host offers it and your plugins are compatible, go ahead. Its advantages over 8.4 are cosmetic from the perspective of a regular business site.

Leave PHP 8.6 for later. The RC lands September 24, the final release November 19, 2026. The new features are interesting for developers: partial function application, a built-in clamp() function, a native polling API. For a WordPress site owner something else matters: the first weeks after release are when plugin authors are still patching compatibility. The sensible moment for 8.6 is spring 2027.

How to check what your site runs on

Three ways, simplest first.

In the WordPress dashboard go to Tools -> Site Health -> Info -> Server. The PHP version row tells you everything.

Via WP-CLI:

wp cli info | grep "PHP version"

On mDiv hosting you see and change the version in the panel, under Websites -> [domain] -> PHP. The dropdown shows available versions from 7.4 to 8.4, the change reloads php-fpm automatically and takes effect in under a minute.

How to upgrade without breaking the site

The procedure is short, but the order matters.

Step 1, backup. A full copy of files and database before any change. On hosting with daily backups you have one anyway, but an on-demand copy right before the change takes 2 minutes and can save your evening.

Step 2, the suspect list. List active plugins and catch the ones already throwing warnings:

wp plugin list --status=active --format=csv > active-plugins.csv
tail -n 50 wp-content/debug.log | grep -i "deprecated"

Plugins logging Deprecated: Creation of dynamic property, or ones without an update in two years, are your candidates for trouble. Check for newer releases before you touch the PHP version.

Step 3, staging. If you have a test environment, bump the version there first and click through the critical paths: home page, contact form, and in a shop the cart and checkout. On mDiv hosting you get staging on request.

Step 4, the production change. Preferably on a weekday morning, not Friday evening. Right after the change, verify the same paths as on staging and glance at debug.log.

Step 5, the escape plan. If something breaks, you switch the dropdown back to the previous version and the site runs as before. A PHP version change is fully reversible, which makes it the safest major update you can perform.

The whole thing takes fifteen minutes on a typical business site. On a shop with twenty plugins, budget an hour including tests.

Don't want to do this yourself?

This is exactly the kind of work we take off your plate with our care plans: we test plugin compatibility, bump the version on staging, then on production, and watch the logs afterwards. And if your current host only offers PHP 8.1 or charges extra for newer versions, migrating to mDiv is free and includes moving the site along with setting the right PHP version.

An old interpreter won't break your site tomorrow. But the difference between a site that receives patches and one that doesn't always reveals itself at the worst possible moment. The December deadline is a good excuse to close this topic in fifteen minutes before it becomes a project.