PHP 8.2 reaches end of life in December. Is your Drupal or WordPress site ready?

PHP 8.2 stops receiving security fixes on 31 December 2026. After that date, any new vulnerability in the interpreter stays open on 8.2 servers for good. PHP 8.1 already reached this point at the end of 2025. If your site runs on either version, the upgrade belongs on this quarter's plan, not next year's.

Why it matters more than usual this year

The PHP2Shell flaws disclosed in October show what an unsupported runtime costs you. Supported branches got a fixed release the same day. End-of-life branches only got source patches, which most hosting providers will never build or ship. A site on an unsupported PHP version has no straightforward way to close a vulnerability like that.

Where Drupal and WordPress stand

• Drupal 11 already requires PHP 8.3 or newer, so Drupal 11 sites are covered
• Drupal 10 still runs on older PHP versions, so many Drupal 10 sites are sitting on 8.1 or 8.2 without anyone having noticed
• WordPress core runs on newer PHP versions, but older plugins and bespoke themes are where upgrades usually break
• Composer-managed sites may have PHP version constraints pinned in composer.json that need lifting first

What usually breaks

Core is rarely the problem. The failures we see come from contributed modules or plugins that are no longer maintained, custom code that relied on deprecated behaviour (dynamic properties are the most common one since PHP 8.2), and old libraries that were vendored into a theme years ago and never updated.

A sensible upgrade path

• Inventory every site and the PHP version it actually runs in production, not what the documentation says
• Run a static compatibility scan (PHPCompatibility via PHP_CodeSniffer) against custom modules, themes and plugins
• Upgrade staging to PHP 8.3 or 8.4, then run the full editorial and checkout workflows, not just the homepage
• Fix deprecation notices in logs before switching production, because today's deprecations become the next version's fatal errors
• Schedule the production switch with a rollback path to the previous PHP-FPM pool