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
| PHP | Status today | Security fixes until |
|---|---|---|
| PHP 8.2 | Security fixes only | 31 December 2026 |
| PHP 8.3 | Security fixes only | 31 December 2027 |
| PHP 8.4 | Active support | 31 December 2028 |
| PHP 8.5 | Active support | 31 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 becomefunction 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$escapeargument to be passed explicitly. Relying on the default is deprecated, which matters for product and order import/export. php.net - Error handling:
trigger_error()withE_USER_ERRORis deprecated, and theE_STRICTconstant is deprecated. php.net - Smaller behaviour changes:
exit()now throws a TypeError on invalid arguments, some resources (DBA, ODBC, SOAP) became objects, andmysqli_ping()is deprecated. php.net
PHP 8.3
get_class()andget_parent_class()without arguments are deprecated, as is++or--on empty or non-numeric strings. php.netrange()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()andutf8_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 release | Supported 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.9 | 8.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
| Laravel | PHP | Status |
|---|---|---|
| Laravel 11 | 8.2 – 8.4 | End of life (security fixes ended 12 March 2026) |
| Laravel 12 | 8.2 – 8.5 | Security fixes only, until 24 February 2027 |
| Laravel 13 | 8.3 – 8.5 | Supported, 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
- Inventory: PHP version, platform version, and every plugin, extension or Composer package with its last update date.
- Update the platform to a version that supports your target PHP (section 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.
- Scan the code with the tools below, and switch on deprecation logging so you see what PHP itself complains about.
- Fix or replace what breaks: update plugins, replace abandoned ones, fix custom code.
- Test what earns money: checkout and payment, account login, forms and emails, imports and exports, cron jobs.
- 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-contentfolder 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
- PHP: supported versions
- PHP: migrating from 8.2 to 8.3
- PHP: migrating from 8.3 to 8.4
- WordPress: PHP compatibility and WordPress versions
- WordPress: requirements
- WordPress: PHP version usage statistics
- WooCommerce: server requirements
- Adobe Commerce: system requirements
- Adobe Commerce: lifecycle policy
- Laravel: release support policy
- Rector
- PHPCompatibility for PHP_CodeSniffer
- PHPStan: configuration reference (phpVersion)
- Adobe: Upgrade Compatibility Tool
- Laravel Shift
- cPanel: MultiPHP Manager
- Plesk: PHP settings
