Guide · PHP
PHP 8.2 security support ends on 31 December 2026.
The PHP project’s security support for PHP 8.2 ends on 31 December 2026; after that, it gets no fixes of any kind. Sites and apps keep running, but new vulnerabilities stay open. Move to PHP 8.4, supported until 31 December 2028, or to 8.3, supported until 31 December 2027, if something you rely on isn’t ready.
- Ends
- 31 Dec 2026
- Version
- PHP 8.2
- Move to
- PHP 8.4, to 31 Dec 2028
- WordPress
- Recommends 8.3+
- Verified
- 7 Oct 2026
- What ends
- Security fixes for PHP 8.2 from the PHP project. Bug fixes already stopped at the end of 2024.
- When
- . PHP 8.1 and older are already past end of life.
- Move to
- PHP 8.4, with security fixes until 31 December 2028, or 8.3, until 31 December 2027.
- Who it affects
- Any WordPress site, WooCommerce store or custom PHP app whose server runs PHP 8.2 or older.
- First step
- Check which PHP version your site or app runs. If it’s 8.2 or older, test it on PHP 8.4 on a copy before switching the live one.
- Source
- php.net’s PHP supported versions, dates verified 7 October 2026.
Before you change anything. This guide is general information, not advice for your system. The dates and steps come from the PHP project’s, WordPress’s and WooCommerce’s published pages, checked on 7 October 2026, and those projects can change them, so confirm on the linked source before you plan around a date. Back up, test every change on a copy that isn’t in production, keep a way back, and follow your own change process. You follow these steps at your own risk (terms). SnowDriven isn’t affiliated with the PHP project, WordPress or WooCommerce (trademarks).
What ends, and what doesn’t
End of life is about fixes from the PHP project. Nothing switches off.
Each PHP version gets two years of active support, with bug and security fixes, then two years of fixes for critical security issues only. After that it reaches end of life: no more releases at all. PHP 8.2 has been in its security-only years since January 2025, and they end on 31 December 2026.
A site on PHP 8.2 keeps working on 1 January 2027. What changes is that any security problem found in PHP 8.2 after that date won’t be fixed by the PHP project. The PHP project warns that people on end-of-life versions may be exposed to unpatched security vulnerabilities.
Hosting companies decide which PHP versions they offer, and they handle end-of-life versions in different ways. Some move sites to a newer version themselves, and some offer paid extended support. Check your host’s notices, so the change happens when you choose rather than when they do.
Running .NET as well? Microsoft’s runtimes follow their own calendar: see .NET 8 and 9 end of support and .NET Framework 4.6.2 end of support.
| Version | Released | Bug fixes until | Security fixes until |
|---|---|---|---|
| PHP 8.2 | 8 Dec 2022 | 31 Dec 2024 | 31 Dec 2026 |
| PHP 8.3 | 23 Nov 2023 | 31 Dec 2025 | 31 Dec 2027 |
| PHP 8.4 | 21 Nov 2024 | 31 Dec 2026 | 31 Dec 2028 |
| PHP 8.5 | 20 Nov 2025 | 31 Dec 2027 | 31 Dec 2029 |
Check your PHP version
It takes a minute. Check the live site, and any staging copy too.
WordPress or WooCommerce
In the WordPress dashboard, go to Tools → Site Health → Info and open the Server section. It lists the PHP version the site is running on.
Your hosting control panel shows it too, usually on a page called something like PHP settings or PHP version. That’s also where most hosts let you change it.
A custom app
On the server, run:
php -vThe command-line PHP can be a different version from the one serving the web app, so check what the web server uses as well, for example in the hosting panel or your deployment configuration.
Then look at composer.json: the php entry under require says which versions the app claims to support.
WordPress and WooCommerce sites
WordPress itself is ready. The question is your theme and plugins.
WordPress recommends PHP 8.3 or greater. Its compatibility table marks WordPress 6.7 and later as compatible with PHP 8.4, and 6.9 and later with PHP 8.5. WooCommerce recommends PHP 8.3 or greater, tested up to PHP 8.4, on WordPress 6.9 or later. That makes PHP 8.4 the target for most sites and stores.
Those statements cover WordPress and WooCommerce themselves. WordPress notes that it is rarely used without a theme or plugins, and those are where problems on a newer PHP usually come from.
How many WordPress sites still run PHP 8.2 or a version the PHP project no longer patches? Our end-of-life PHP tracker has the latest share, from a daily snapshot of WordPress.org’s own figures.
Back up
Take a full backup of files and database, and make sure you know how to restore it.
Use a staging copy
Do the upgrade on a copy of the site first, not the live one. Ask your host whether they offer a staging site.
Update everything
Update WordPress, the theme and every plugin. Remove plugins you no longer use.
Check each plugin
Look at each plugin’s page and changelog for recent updates and PHP version notes. One with no updates in years needs a replacement or an owner.
Switch PHP on staging
Change the PHP version in the hosting panel, or ask your host to.
Test what earns money
Forms, search, logins, and for a store a full order: cart, checkout, payment, emails and stock. Then switch the live site.
Keep a way back
Note the old PHP setting. If something breaks, switch back, fix it on staging and try again.
Custom PHP apps
Laravel, Symfony or plain PHP: find the problems with tools, prove the fixes with tests.
What changes after 8.2
PHP publishes a migration guide for each version, listing backward-incompatible changes, deprecations and other changes: 8.2 to 8.3 and 8.3 to 8.4. Read them in order, or start with our PHP 8.2 to 8.4 reference, which sorts them by how likely each is to hit a plugin, theme or app. A few worth checking first:
- Dynamic properties, deprecated in PHP 8.2: setting a property a class never declared.
- Implicitly nullable parameters, deprecated in PHP 8.4: a typed parameter with a default of
nullbut no?or|nullin its type. - Removed extensions in PHP 8.4: IMAP, OCI8, PDO_OCI and PSpell moved out of PHP into PECL. Code that reads mailboxes or talks to Oracle needs a plan.
Deprecations warn rather than fail, but each one is code a later version won’t run.
Find, fix, test
- Static analysis. PHPCompatibility checks code against a target PHP version through PHP_CodeSniffer. Checks for recent versions are in its 10.0 pre-release; the last stable release dates from 2019.
- Automated fixes. Rector rewrites code for newer PHP versions. Preview with
--dry-runand review every change. - Tests. Run the test suite on the new PHP version in CI with deprecation notices turned on. Where there are no tests, write a few around the workflows the business depends on first.
- Dependencies. Update Composer packages to versions that support the new PHP; some will need major upgrades of their own.
Framework versions and the PHP they support
- Laravel 11
- PHP 8.2–8.4. Security fixes ended 12 March 2026.
- Laravel 12
- PHP 8.2–8.5. Security fixes until 24 February 2027.
- Laravel 13
- PHP 8.3–8.5. Security fixes until 17 March 2028.
- Symfony 6.4 LTS
- Requires PHP 8.1 or higher. Security fixes until November 2027.
- Symfony 7.4 LTS
- Requires PHP 8.2 or higher. Security fixes until November 2029.
- Symfony 8
- Requires PHP 8.4 or higher.
From each project’s support pages, linked under the sources below. An app on Laravel 10 is limited to PHP 8.3 at most, and older versions can’t move past PHP 8.2 without a framework upgrade; none of them get security fixes any more.
Which path fits
Find the row closest to your situation.
| If | Then |
|---|---|
| A WordPress site on hosting where you pick the PHP version in a control panel | Back up, update everything, try PHP 8.4 on a staging copy, then switch the live site. Keep the old setting written down in case you need to switch back. |
| A WooCommerce store | Aim for PHP 8.4, the newest version WooCommerce says it’s tested with. Test a full order on staging, including payment and emails, before switching the live store. |
| A plugin or theme has had no updates in years | Find a maintained replacement, or have someone fix and own it. Don’t let one abandoned plugin hold the whole site on an unsupported PHP. |
| A Laravel or Symfony app on a supported framework version | Raise the PHP version in CI first, fix what the tests and deprecation notices find, then upgrade staging and production. |
| An app on Laravel 11 or older, or one with no tests | Move PHP to 8.3 or 8.4 now where the framework supports it (Laravel 10 stops at 8.3, Laravel 9 and older can’t go past 8.2 without a framework upgrade), and plan the framework upgrade as its own project with tests around the behaviour that matters. |
A plan to 31 December
Leave December for the switch, not the discovery.
October: find out
List every site and app on PHP, with its PHP version, its host and who can change it. Note abandoned plugins, old frameworks and anything using IMAP or Oracle.
November: test
Upgrade a staging copy to PHP 8.4, or 8.3 where something isn’t ready. Fix what breaks, replace what can’t be fixed, and run the workflows that matter.
Early December: switch
Move production with a backup and a way back, outside your busiest days. A store in peak season may want to switch in November.
After: keep current
Write down when your new version’s support ends, and plan the next move before then rather than in its last month.
How we can help
If you’d rather not do the testing and fixing yourself.
WordPress and WooCommerce
The PHP upgrade, done on staging first
We update or replace what won’t run on the newer PHP, test the site or store on staging, switch it with a way back, and leave updates on a schedule.
Websites and stores Ask about a WordPress site Ask about a WooCommerce store
Custom apps · Scoped and quoted on its own
Modernization audit
The code, dependencies, data, hosting and releases reviewed, the risks ranked in a written report, and a step-by-step plan. Nothing beyond the audit is committed until you decide to go further.
How a modernization runs See a sample report Start with an audit
No email needed
Modernization readiness check
Ten yes-or-no questions about a custom system, including whether it runs on a version that no longer gets updates, and the first step we’d suggest.
Questions about PHP 8.2 end of life
Will my site stop working on 1 January 2027?
No. End of life doesn’t switch anything off. After 31 December 2026 the PHP project no longer releases fixes for PHP 8.2, including security fixes, so any vulnerability found after that date stays open on servers still running it.
Should we move to PHP 8.3 or 8.4?
PHP 8.4 where your software supports it. It gets security fixes until 31 December 2028, while 8.3 gets them only until 31 December 2027, so moving to 8.3 means doing this again a year sooner. WooCommerce lists 8.4 as the newest version it’s tested with.
Is WordPress compatible with PHP 8.4?
Yes, from WordPress 6.7. WordPress’s compatibility table marks 6.7 and later as compatible with PHP 8.4, and 6.9 and later with PHP 8.5. That covers WordPress itself, not your theme and plugins, which is why testing on a staging copy matters.
Our host offers to keep PHP 8.2 running after December. Is that enough?
It buys time, not support from the PHP project. Some providers offer their own extended support for end-of-life PHP versions; ask what it covers and for how long. Upgrading remains the lasting fix.
Do deprecation notices mean the site is broken?
No. A deprecation notice is a warning about code that will not work in a future version of PHP. The code still runs on the version that warns, but each notice is a fix to make before the version that removes it.
Sources · support dates verified 7 October 2026
- PHP: Supported versions
- PHP: Unsupported branches
- PHP 8.5 release announcement
- Migrating from PHP 8.2 to PHP 8.3
- Migrating from PHP 8.3 to PHP 8.4
- PHP 8.2 deprecated features
- PHP 8.4 deprecated features
- PHP 8.4 removed extensions
- WordPress requirements
- PHP compatibility and WordPress versions
- WordPress: Update PHP
- WordPress: Site Health screen
- WooCommerce server requirements
- Laravel release notes and support policy
- Symfony releases
- PHPCompatibility for PHP_CodeSniffer
- Rector documentation
Part of SnowDriven Research: see this date in the deadline table beside every other date we track, and how we verify them.
General information, checked on 7 October 2026. Confirm dates with the vendor; follow at your own risk. Terms.
Start a project
Still on PHP 8.2? Let’s plan the upgrade.
Tell us whether it’s a WordPress site, a store or a custom app, and which PHP version it runs. We reply within one business day, with questions or a time to talk.
Pittsburgh, PA · Since 2015 · First step: a 30-minute call