PHP 8.2 End of Life: What WordPress Site Owners Must Do
Written by Kamran, Founder, 3xRevenue. Published · 9 min read.
PHP 8.2 stops getting security fixes on December 31, 2026. By WordPress.org's own numbers, about 56% of WordPress sites will run an unsupported PHP version on January 1, 2027. The fix is to move to PHP 8.3 or newer, after a backup and a test on a copy of your site.
Here is how it usually goes. Your site was built in 2021, it still works, and nobody has logged into the hosting account since. Then one morning a host email says your PHP version is "end of life," and you have no idea what that means.
You do not need to learn to code to deal with this. You need to know what your site runs on, what to ask your host, and what to test. Start by checking what platform sits under your site with our free website tech checker, then use this guide to plan the switch.
What stops working on December 31, 2026
Nothing breaks at midnight. Your site keeps loading on January 1. What stops is the flow of security fixes for the language your site runs on.
PHP is the code that runs most WordPress sites on the server. Each PHP version gets about 2 years of bug fixes, then 2 more years of security-only fixes. After that, new holes are found and never patched. The official PHP support schedule lists the dates for every version.
The last 8.2 release, 8.2.35, came out on October 22, 2026, and it fixed security bugs. After December 31, fixes like that stop for 8.2 sites.
| PHP version | Security fixes end | Share of WordPress sites (Oct 31, 2026) |
|---|---|---|
| 7.4 and older | Already ended | About 20% |
| 8.0 | Already ended | 3.4% |
| 8.1 | Already ended | 9.4% |
| 8.2 | December 31, 2026 | 22.9% |
| 8.3 | December 31, 2027 | 27.6% |
| 8.4 | December 31, 2028 | 10.4% |
| 8.5 | December 31, 2029 | 6.0% |
Source: php.net supported versions page and WordPress.org PHP stats, both checked October 31, 2026.
Get PHP updates handled for you
Is your site on PHP 8.2? Three ways to check in 5 minutes
You can find your PHP version without touching any code. Pick whichever login you have.
- WordPress dashboard. Go to Tools, then Site Health, then the Info tab, then Server. The line "PHP version" shows the number.
- Hosting control panel. In cPanel, look for "Select PHP Version" or "MultiPHP Manager." Other hosts put it under Settings or Advanced.
- Ask your host. Send one line: "Which PHP version does my site run, and what happens to it after December 31, 2026?"
If you use Wix, Squarespace or Shopify, you can stop here. Those platforms run the servers for you, so PHP is their job, not yours.
Ask the host question in writing, even if you know the version. Hosts set their own rules for old PHP. Some move sites on their own schedule, which can break an old plugin with no warning.
Which PHP version should you move to?
Move to PHP 8.3 or 8.4 in most cases. WordPress lists "PHP version 8.3 or greater" as its recommended setup. PHP 8.4 buys you one extra year, with security fixes until December 31, 2028.
Your WordPress version sets the ceiling. WordPress 6.4 added support for 8.3, 6.7 for 8.4, and 6.9 for 8.5. So update WordPress itself before you change PHP.
| Your situation | What it means on January 1, 2027 | What to do | When |
|---|---|---|---|
| PHP 7.4, 8.0 or 8.1 | No security fixes, some already for years | Move to 8.3 or 8.4 | This month |
| PHP 8.2 | No security fixes from January 1 | Move to 8.3 or 8.4 | Before December 15 |
| PHP 8.3 | Security fixes until end of 2027 | Plan the next move for 2027 | No rush |
| PHP 8.4 or 8.5 | Security fixes until 2028 or 2029 | Keep plugins updated | No action |
| Wix, Squarespace, Shopify | The platform handles PHP | Nothing to do here | None |
Source: php.net supported versions and WordPress.org PHP compatibility table. Timing is our recommendation.
Why December 15 and not December 31? Hosts and developers get busy in late December. You also want a week to spot problems before the holidays.
Skip PHP 8.5 unless every plugin you rely on says it supports it. Newer is not better if your booking plugin breaks.
Six checks before you switch PHP versions
Most PHP problems come from one old plugin or theme, not from WordPress itself. These six checks catch that before your customers do.
1. Make a backup and restore it once
Take a full backup of files and the database. Then restore it to a test spot to prove it works.
Example: your host's backup tool saves a copy, and you restore it to a staging site. Quick check: the restored copy loads and you can log in.
2. Update WordPress, then plugins, then the theme
Update in small batches and look at the site after each batch. One batch of 20 updates hides which one broke things.
Example: update WordPress, then 5 plugins, then the next 5. Quick check: the home page and contact page still load after each batch.
3. Find plugins nobody has updated in 2 years
Old plugins are the most likely to break on a new PHP version. On each plugin's WordPress.org page, look at "Last updated" and "Tested up to."
Example: a slider plugin last updated in 2022 needs a replacement or removal. Quick check: every plugin was updated within the last 12 months.
4. Switch PHP on a staging copy first
A staging site is a private copy of your site. Most hosts create one in a few clicks. Change PHP there, not on the live site.
Example: set staging to PHP 8.3 and leave live on 8.2. Quick check: the staging site loads with no error message at the top.
5. Test the pages that bring in money
Click through every path a customer takes. Forms, bookings, checkout, logins and emails matter more than the About page.
Example: send a test quote request and confirm the email lands in your inbox. Quick check: every form sends, and every payment works in test mode.
6. Switch live, then watch for 7 days
Change PHP on the live site in a quiet hour, then repeat check 5. Keep the old version noted so you can switch back in 2 minutes.
Example: switch on a Tuesday at 7 AM, not on a Friday evening. Quick check: form leads keep arriving at the normal rate all week.
The math for an 8-page plumbing site on PHP 8.1
This is an example, not a real client. It shows why a few hours of testing is cheap next to a silent broken form.
Picture a plumbing company with an 8-page WordPress site on PHP 8.1. It runs 18 plugins, including a quote form and a booking plugin. The owner asks the host to switch PHP and skips testing.
| Item | Example figure |
|---|---|
| Quote requests from the site per month | 40 |
| Share that turn into booked jobs | 1 in 3 |
| Average job value | $350 |
| Days the broken form goes unnoticed | 7 |
| Our estimate of hours to test and switch properly | 4 to 6 |
Source: 3xRevenue example figures and time estimate, not client data.
Here is the math. 40 requests a month is about 9 a week. A week with a dead form loses about 9 requests. If 1 in 3 books, that is 3 lost jobs, or about $1,050 in work.
Compare that with 4 to 6 hours of careful testing. The test is almost always cheaper than one quiet, broken week.
The bigger risk is security. A site that stays on an old PHP version collects unpatched holes year after year. Cleaning up after a hack, like a full website rescue, costs far more than an update.
Mistakes that turn a PHP update into a broken site
- Switching on the live site first. If something breaks, customers see the error before you do. Always use staging first.
- Trusting a backup you never restored. A backup that fails to restore is not a backup. Test it once.
- Updating 25 plugins at once. When the site breaks, you cannot tell which plugin did it. Go in batches of 5.
- Only checking the home page. The home page often loads fine while the form behind it fails. Send a real test lead.
- Waiting until December 30. Your host or developer may be booked or on holiday. Aim to finish by December 15.
- Paying for "extended support" without a plan. Some hosts sell extra time on old PHP. It buys months, not a fix, so set a move date anyway.
If your site is old enough that most plugins are abandoned, the PHP switch may not be worth it. A rebuild on a current stack can be cheaper than patching. Our Webflow vs WordPress vs Framer comparison helps you pick if you go that way.
FAQ
Will my website go down when PHP 8.2 reaches end of life?
No. Your site keeps running on January 1, 2027. It just stops getting security fixes, so new holes stay open.
Do I need to do anything if my site is on Wix or Squarespace?
No. Hosted builders like Wix, Squarespace and Shopify manage the server and PHP for you. This deadline is for self-hosted WordPress and other PHP sites.
Can my web host upgrade PHP for me?
Often yes, and many hosts let you switch it in one click. But the host will not test your plugins or forms. Ask what their policy is for 8.2 sites, and test first.
What if something breaks after I switch PHP?
Switch back to the old version in your hosting panel, which usually takes 2 minutes. Then find the plugin or theme that caused it on your staging copy. Fix or replace it before you try again.
Is PHP 8.3 safe to use until 2028?
No. PHP 8.3 gets security fixes until December 31, 2027. PHP 8.4 lasts until December 31, 2028, so pick 8.4 if your plugins support it.
How long does a PHP upgrade take for a small business site?
For a small site with up-to-date plugins, our estimate is 4 to 6 hours including testing. Sites with old or custom plugins take longer. Budget extra time if a plugin needs replacing.
Get the PHP switch done before the holidays
You can do this yourself if your plugins are current and you have a staging copy. If you would rather not, or your site is old and fragile, hand it to people who do this every week. Our care plan covers PHP and plugin updates, backups and uptime checks, even on sites we did not build. If the site is too far gone, we can build you a new website in 7 days, from $3,000.