PHP 8.6 Is Coming: How to Upgrade Safely
PHP 8.6 is currently scheduled for general release on 19 November 2026, and you do not need to rush onto it: the safe move today is to make sure you are on a PHP version that still gets security fixes, then test 8.6 on a staging copy of your site.
This post is for owners of WordPress, custom PHP, Laravel or other PHP-based sites who want a calm plan. You will get the release date, a table of which PHP versions are still supported, what "breaking change" means for your site, and a numbered upgrade order you can start this week. The date comes from the PHP release schedule and may change, so check php.net for final confirmation.
PHP 8.6 release date and what "GA" means
PHP is the programming language that runs a large share of websites, including WordPress. "GA" means general availability: the first version the PHP team calls ready for normal production use.
PHP 8.6 is currently scheduled for GA on 19 November 2026. Schedules can move, so check php.net for final confirmation. The PHP project has shipped a new minor version every November for the last few years. PHP 8.4 came out on 21 November 2024 and PHP 8.5 on 20 November 2025, according to the official PHP supported versions page.
For current news, release notes and downloads, use the official site at php.net. Treat any feature list you read elsewhere as a preview until the final release notes land.
Which PHP versions keep security support?
This is the part that matters most to site owners. "Security support" means the PHP team still releases fixes for newly found vulnerabilities. Once it ends, a flaw found in that version stays unfixed.
Here is the schedule from the official supported versions page (snapshot dated 6 November 2026):
| PHP version | Released | Active support until | Security fixes until |
|---|---|---|---|
| 8.2 | 8 Dec 2022 | 31 Dec 2024 | 31 Dec 2026 |
| 8.3 | 23 Nov 2023 | 31 Dec 2025 | 31 Dec 2027 |
| 8.4 | 21 Nov 2024 | 31 Dec 2026 | 31 Dec 2028 |
| 8.5 | 20 Nov 2025 | 31 Dec 2027 | 31 Dec 2029 |
Per that page, each version gets two years of active support (bug fixes and security fixes), then two more years of security-only fixes.
What this means in plain terms:
- If you run PHP 8.2: security support ends on 31 December 2026, less than two months from now. Plan a move to 8.3, 8.4 or 8.5 before then.
- If you run 8.3, 8.4 or 8.5: you are fine today. Moving to 8.6 can wait until your plugins, themes and code are tested on it.
- If you run 8.1 or older: it does not appear in the table above, so it is no longer on the supported list. Upgrading is overdue, but you can do it calmly and in order.
After 8.6 arrives, the newest versions to choose from will be 8.3, 8.4, 8.5 and 8.6. Check the supported versions page for 8.6's own end dates once it is listed.
Why this matters for security: running software with known, unfixed flaws is a common way sites get compromised. OWASP, the nonprofit behind the well-known web risk lists, calls this Vulnerable and Outdated Components. Staying on a supported PHP version is a simple way to reduce that risk. It does not make a site unhackable, but it removes an easy target.
What are breaking changes and deprecations?
Two terms come up in every PHP release:
- Deprecation: PHP warns that a feature will be removed later. Your site still works, but it may log a notice.
- Breaking change: something behaves differently, or was removed, so old code can fail.
Most small sites feel these through plugins, themes and old custom code, not through the PHP language itself. A plugin that has not been updated in years is the usual source of trouble.
We are not going to copy a full list of 8.6 deprecations into this post. Release candidates change until GA, and a stale list is worse than none. Instead, read the 8.6 release notes and migration or upgrade notes on php.net once they are published.
If you have a developer, send them those notes and ask one question: "Does anything we use appear in the deprecation or removal list?"
A safe upgrade order
The goal is to find problems on a copy of your site, never on your live customers. Follow these steps in order.
1. Find out what you run today
Check your current version from the command line:
php -v
No shell access? Try these instead:
- WordPress: go to Tools > Site Health > Info > Server and read the PHP version.
- cPanel hosting: open MultiPHP Manager.
- Other hosts: look for "PHP version" in your hosting dashboard.
If you are on 8.2 or older, that is your first job, ahead of anything to do with 8.6.
2. Make a backup and a staging copy
Take a full backup of files and database. Then create a staging site, which is a private copy of your site used for testing. Many hosts offer one-click staging. Never test a PHP upgrade only on the live site.
3. Test on PHP 8.5 first
Move your staging copy to PHP 8.5 before 8.6. It is the current stable release. Most problems you find on 8.5 will also show up on 8.6, though 8.6 can add its own changes, so you still retest on it. Fixing issues in two small steps is easier than one big jump.
On staging, turn on error logging without showing errors to visitors. In php.ini (or your host's PHP settings panel):
error_reporting = E_ALL
display_errors = Off
log_errors = On
Browse the site, submit forms, run a test checkout and log in to the admin area. Then read the error log. Lines marked "Deprecated" are early warnings worth fixing.
4. Check your extensions
PHP extensions are add-on modules, such as image handling or database drivers. List what is installed:
php -m
Compare the list with what your site needs. Ask your host whether each extension is available for the new PHP version. Missing extensions are a common reason an upgrade fails.
5. Run the Composer platform check
If your project uses Composer (PHP's package manager), you can run this command:
composer check-platform-reqs
Run it on the staging server while it is switched to the PHP version you want to test (for example 8.5, later 8.6). Otherwise it only confirms your current version. The command checks the PHP version and extensions of the machine it runs on against what your composer.lock requires. It will not find deprecated code inside your packages. See the Composer documentation. Also run composer outdated to spot packages that need updating, and update them before the PHP change.
6. Update plugins, themes and code
Update WordPress core, plugins and themes to their latest versions on staging. If a plugin is abandoned and breaks, replace it. Do not leave a broken plugin in place just to keep an old PHP version running.
7. Test on PHP 8.6
When 8.6 is available from your host, repeat steps 3 and 4 on staging with 8.6. Look at the error log again. If everything is clean for a week of normal use, you are in good shape.
8. Switch production and watch it
Pick a quiet hour, keep your backup ready, and switch the live site. Watch the error log and check key pages straight after. If something breaks, switch back to the previous version in your host panel and go back to staging.
Most owners do not need to be on 8.6 in its first week. Moving to 8.6 after your plugins and host confirm support is a perfectly sound plan.
Quick checklist
- [ ] I know my current PHP version.
- [ ] If I run 8.1 or older, I am upgrading now. If I run 8.2, I have a date to move before 31 December 2026.
- [ ] I have a recent backup and a staging site.
- [ ] I tested on PHP 8.5 and read the error log.
- [ ] I checked extensions with
php -m. - [ ] I ran
composer check-platform-reqs(if I use Composer). - [ ] Plugins and themes are updated.
- [ ] I tested on 8.6 on staging before changing production.
Do not forget the rest of your security
A new PHP version fixes flaws in PHP itself. It does not fix weak passwords, missing security headers or a vulnerable plugin setting. Two free ways to see the wider picture:
- Run the free website security check for a quick outside view of your site.
- Use the security headers tool to see whether your site sends the browser protections it should.
If you are wondering how exposed a site really is, our guide Is my website hackable? explains what attackers look at first.
Key takeaways
- PHP 8.6 is currently scheduled for GA on 19 November 2026 (check php.net for final confirmation). Waiting a little before adopting it is normal and safe.
- PHP 8.2 security support ends on 31 December 2026. Move to 8.3, 8.4 or 8.5 before then if you are still on it.
- Test on a staging copy, on PHP 8.5 first, then 8.6. Read the error log for "Deprecated" lines.
- Check extensions with
php -mand runcomposer check-platform-reqsbefore you switch. - Keep plugins and themes updated. Outdated plugins and themes are the most common cause of upgrade problems on small sites.
Next step
An upgrade keeps PHP current, but it will not tell you what else is exposed on your site. For that, a person needs to look. The $49 Circuit audit is a manual review of your whole site by a human security engineer, with a written report of each issue, its severity, the evidence and the exact fix. It is a focused audit for small sites, not a multi-week enterprise test or a compliance certificate. See pricing if you want to know what you would get.
A real human security engineer audits your whole site by hand and sends a full report: every issue, its severity, and the exact fix. From $49, with a 14-day money-back guarantee.
See pricing