PHP 8.2 end of life: upgrading to PHP 8.3 or 8.4

PHP 8.2 gets its last security fix on 31 December 2026. Here's what to move to, what breaks on the way, and what WordPress, WooCommerce, Magento and Laravel sites need to change first.

As of 28 October 2026. Versions and dates are from each vendor's own pages, linked at the bottom.

In 30 seconds

  • What happens: after 31 December 2026, PHP 8.2 gets no more security fixes. PHP calls an end-of-life release one whose users "may be exposed to unpatched security vulnerabilities".
  • Who: about 23% of WordPress sites run PHP 8.2 today, and another third run versions that are already end of life (wordpress.org statistics, 28 October 2026).
  • What to do: move to PHP 8.3 or 8.4 before the end of the year, on a staging copy first. Most of the work is in plugins, extensions and custom code, not PHP itself.

1. Which version to move to

PHPStatus todaySecurity fixes until
PHP 8.2Security fixes only31 December 2026
PHP 8.3Security fixes only31 December 2027
PHP 8.4Active support31 December 2028
PHP 8.5Active support31 December 2029
  • PHP 8.3 is the smallest step and what WordPress recommends, but it only buys you one more year: its security support ends 31 December 2027.
  • PHP 8.4 is supported until the end of 2028 and is usually the better target, if your platform version supports it (see section 3). It also has the most deprecations to deal with (section 2).
  • Whatever you choose, run the latest patch release of that branch: on 28 October 2026 those were 8.3.36 and 8.4.27, which also fix the PHP2Shell vulnerabilities.

2. What breaks going from 8.2 to 8.3 and 8.4

These are the changes from PHP's own migration guides that most often show up in real plugins and shop code. Deprecations only log a notice for now, but they become errors in a later version, so fix them while you're in there.

PHP 8.4

  • Implicitly nullable parameters are deprecated. function foo(Bar $x = null) must become function foo(?Bar $x = null). This is the one you'll see most in older plugins and extensions. php.net
  • IMAP, OCI8, PDO_OCI and PSpell were moved out of PHP into PECL. Anything that imports mail with imap_* functions (helpdesk and mail-import plugins) stops working unless your host installs the PECL extension. php.net
  • CSV functions (fputcsv(), fgetcsv(), str_getcsv()) now expect the $escape argument to be passed explicitly. Relying on the default is deprecated, which matters for product and order import/export. php.net
  • Error handling: trigger_error() with E_USER_ERROR is deprecated, and the E_STRICT constant is deprecated. php.net
  • Smaller behaviour changes: exit() now throws a TypeError on invalid arguments, some resources (DBA, ODBC, SOAP) became objects, and mysqli_ping() is deprecated. php.net

PHP 8.3

  • get_class() and get_parent_class() without arguments are deprecated, as is ++ or -- on empty or non-numeric strings. php.net
  • range() now throws errors on bad input instead of guessing. php.net

Already deprecated in 8.2 (likely in your logs now)

  • Dynamic properties, unless the class has #[\AllowDynamicProperties]; "${var}" string interpolation; utf8_encode() and utf8_decode(). If your error log is full of these on 8.2, that's your to-do list. php.net

3. What your platform needs first

WordPress and WooCommerce

  • WordPress 7.0 and 7.1 support PHP 7.4 up to 8.5, and wordpress.org recommends PHP 8.3 or greater. If you're on WordPress 6.4–6.6, the highest PHP it supports is 8.3: update WordPress first.
  • WooCommerce asks for "PHP version 8.3 or greater (tested up to PHP 8.4)".
  • Core is rarely the problem. Old plugins and themes are: check that each one has had an update in the last year and lists your target PHP version, and replace the ones that are abandoned.
  • Tools → Site Health tells you your PHP version is out of date, but it doesn't test whether your plugins work on the new one.

Magento / Adobe Commerce

Adobe only supports specific PHP versions per release:

Magento releaseSupported PHP
2.4.6 (latest patch 2.4.6-p15)8.2, 8.1
2.4.7 (latest patch 2.4.7-p10)8.3, 8.2
2.4.8 (latest patch 2.4.8-p5)8.4, 8.3
2.4.98.5
  • So leaving PHP 8.2 means upgrading Magento too: at least 2.4.7 for PHP 8.3, and 2.4.8 for PHP 8.4. Upgrade Magento first, then PHP.
  • 2.4.6 is already past standard support (ended 11 August 2026), which is another reason to move now. See our Magento 2.4.6 guide, which also covers the StyleSmuggler flaw.

Laravel

LaravelPHPStatus
Laravel 118.2 – 8.4End of life (security fixes ended 12 March 2026)
Laravel 128.2 – 8.5Security fixes only, until 24 February 2027
Laravel 138.3 – 8.5Supported, security fixes until 17 March 2028

Laravel 11 already runs on PHP 8.3 and 8.4, but Laravel 11 itself is end of life. If you're touching PHP anyway, plan the move to Laravel 12 or 13 at the same time.

Drupal

Drupal 11 needs PHP 8.3 or newer, and Drupal 10 reaches end of life on 9 December 2026. See our Drupal 10 end-of-life guide.

4. Step by step

  1. Inventory: PHP version, platform version, and every plugin, extension or Composer package with its last update date.
  2. Update the platform to a version that supports your target PHP (section 3).
  3. Make a staging copy on the target PHP version. In cPanel that's MultiPHP Manager (pick the domain, choose the version, Apply); in Plesk it's Websites & Domains → PHP. If the version isn't in the list, ask your host.
  4. Scan the code with the tools below, and switch on deprecation logging so you see what PHP itself complains about.
  5. Fix or replace what breaks: update plugins, replace abandoned ones, fix custom code.
  6. Test what earns money: checkout and payment, account login, forms and emails, imports and exports, cron jobs.
  7. Switch production at a quiet moment, watch the error log for a few days, and keep the old version available to switch back to.

5. Tools that help

  • Rector (free, open source): rewrites code automatically. Its PHP 8.3 and 8.4 sets fix, for example, implicitly nullable parameters and the CSV escape argument. Fast, but review every change it makes.
  • PHPCompatibility for PHP_CodeSniffer (free): scans code for things that break on a given PHP version. The checks for 8.3 and 8.4 are only in the 10.0 alpha releases; the last stable version (9.3.5, from 2019) doesn't know about them. Useful, but expect some false positives.
  • PHPStan (free, open source): static analysis that you can point at a target PHP version. Good at type and API problems; it doesn't catch every deprecation on its own.
  • WordPress: the "PHP Compatibility Checker" plugin is no longer maintained and only checks up to PHP 8.0, so don't rely on it. Use the tools above on your wp-content folder instead.
  • Magento: Adobe's Upgrade Compatibility Tool checks a customised store against a target Magento version, but it's only available for Adobe Commerce, not Magento Open Source.
  • Laravel Shift (paid): automated Laravel upgrades as a pull request, from $19 per upgrade step (12.x → 13.x) to $39 (10.x → 11.x), as listed on its site on 28 October 2026.

Sources