PHP 8.2 end of life: what it means for your WordPress site in 2027

On December 31, 2026, PHP 8.2 reaches end of life. From January 1, 2027, the PHP project stops publishing security fixes for it. PHP is the language WordPress runs on, and a large number of small-business sites still use 8.2 or something older. Your site will not switch off on New Year's Day. What changes is quieter and more dangerous: any new security hole found in that version stays open for good. Here is what that means for a Canadian WordPress site, how to check where you stand, and how to upgrade without breaking anything.

Key takeaways

• PHP 8.2 gets no security fixes after December 31, 2026. PHP 8.1 already reached the same point a year earlier.
• Your site keeps working. End of life is not a shutdown. It is the end of patches.
• The bigger risk is being stuck. An old PHP version stops you updating the plugins and themes that most attacks actually target.
• PHP 8.4 is the sensible target for most sites in 2027. It receives security fixes until the end of 2028.
• Upgrade on a staging copy first. Most problems come from old plugins and custom code, and they show up in testing, not in the switch itself.
• Security is also a legal duty in Canada. Running unsupported software on a site that holds customer data makes it harder to show you took reasonable care.

What "end of life" actually means

Every PHP version goes through the same life cycle. For two years after release it receives active support: bug fixes and security fixes. For the next two years it receives security fixes only. After that it reaches end of life and receives nothing at all. Since a change to the release policy in 2024, those support periods end on December 31 of the relevant year, which makes the dates easy to remember.

End of life does not delete anything or stop your server. A site on PHP 8.2 will load on January 2, 2027 exactly as it did on December 30. The difference is that when a new vulnerability in PHP 8.2 is discovered - and over a version's lifetime, some always are - no official fix will be released. The hole is public, it is permanent and it is easy to scan for.

The PHP support calendar

These dates come from the PHP project's published support schedule. If you are reading this later, check the official php.net supported versions page for the current picture.

Why this matters more for WordPress than for most sites

WordPress itself is written in PHP, and so is every theme and plugin you install. That makes the PHP version the foundation everything else stands on. Two things follow from it.

First, the direct risk. An unpatched PHP version can expose the server to attacks that have nothing to do with WordPress. Automated bots constantly scan the internet for software versions with known holes, and they do not care whether you are a large retailer or a three-person bakery in Kelowna.

Second, and more often in practice, the knock-on risk. Plugin and theme developers stop supporting old PHP versions. New releases - including the security fixes for their own code - start requiring a newer PHP. A site stuck on 8.2 gradually loses the ability to update the plugins that attackers actually target, such as forms, sliders, page builders and e-commerce extensions. The outdated PHP version becomes the reason everything else goes out of date too.

WordPress.org currently recommends PHP 8.3 or newer, and with WordPress 7.0 the minimum supported version rose to PHP 7.4. The minimum is the floor that WordPress will tolerate, not a version you should be running.

How to check which PHP version your site runs

This takes about a minute and you don't need technical skills.

1. Log in to your WordPress dashboard.
2. Go to Tools → Site Health. If your PHP version is outdated, the Status tab usually flags it directly.
3. Open the Info tab and expand Server. The line "PHP version" shows exactly what you are running.

You can also check in your hosting control panel - in cPanel it usually appears as "Select PHP Version" or "MultiPHP Manager" - or simply ask your host. If you don't have access to your hosting account at all, sort that out first. Our article on whether you really own your website explains why access matters.

Isn't my host taking care of this?

Sometimes, but don't assume it. Hosts handle end of life in three very different ways:

• Automatic upgrade. Some managed WordPress hosts move sites to a supported version for you, usually after an email warning. Convenient, but if an old plugin isn't compatible the site can break without anyone testing it first.
• Extended support. Some hosts and server vendors keep patching old PHP versions themselves after the official end of life, sometimes for an extra fee. This buys time, but it is a bridge, not a destination.
• Nothing. Plenty of budget shared hosting simply leaves the old version in place until you change it.

Ask your host three direct questions: Which PHP version is my site running? What will happen to PHP 8.2 sites after December 31, 2026? Can I switch versions myself, and can I switch back if something breaks? If you are reviewing hosting anyway, our guide to domains and hosting in Canada covers what to look for.

Which version should you move to?

• PHP 8.4 - the best target for most sites in 2027. It receives security fixes until the end of 2028, so it gives you two calm years, and most actively maintained plugins support it.
• PHP 8.3 - only as a stepping stone. If an important plugin isn't ready for 8.4 yet, 8.3 keeps you supported, but only until December 31, 2027. You will be doing this again within a year.
• PHP 8.5 - for well-maintained sites. It is the newest release with the longest support, but smaller plugins can lag behind. Choose it if your testing passes cleanly.

Jumping several versions at once, for example from 7.4 straight to 8.4, is possible but riskier. Old sites often need a full plugin review before that jump is safe.

How to upgrade without breaking your site

The switch itself is usually a single setting in the hosting panel. The work is in what you do before and after it.

1. Take a full backup of the files and the database, and confirm you know how to restore it. A backup you have never restored is a hope, not a plan.
2. Update everything else first. Bring WordPress core, your theme and all plugins up to date on the current PHP version, so you are only changing one thing at a time.
3. Audit your plugins. Delete anything you don't use. Look for plugins that haven't been updated in a long time - WordPress.org warns when a plugin "hasn't been tested with the latest major releases". Those are the most likely to break and the most likely to need replacing.
4. Make a staging copy of the site and switch its PHP version there, not on the live site.
5. Test the journeys that make you money: contact and quote forms, bookings, checkout and payment, account logins, and the admin screens you use every week.
6. Read the error log. On staging, enable WordPress debug logging and look for errors and warnings after you click through the site.
7. Switch the live site at a quiet time, with the previous version ready so you can switch back in a minute if needed.
8. Watch it for a week. Check form submissions and orders are still arriving, and keep an eye on the error log.

Our website launch checklist is a useful list of things to re-test after any significant change like this.

What typically breaks, and why

• Abandoned plugins. Code written years ago for PHP 7 may use functions or patterns that newer versions changed or removed.
• Old page builders and bundled premium themes. Themes that came with a page builder or a slider plugin often ship an outdated copy that never gets updated.
• Custom snippets. Code pasted into the theme's functions.php file years ago, often by someone who is no longer around to fix it.
• Dynamic properties. PHP 8.2 deprecated a common coding shortcut called dynamic properties. On newer versions, older code that relies on it fills the logs with warnings, and a future major release is expected to turn those warnings into errors.
• Warnings shown to visitors. If the server is set to display errors, harmless notices can suddenly appear on your pages. On a live site, errors should be logged, never displayed.

What it costs

The cost depends far more on the state of your site than on PHP itself.

• A well-maintained site with current plugins: usually a short job, often covered by a normal maintenance plan.
• A site with several outdated or abandoned plugins: anything from a few hours to a few days, mostly spent finding and testing replacements.
• An old, heavily customised theme that breaks badly on a modern PHP version: this is the point to compare the cost of repairing it with the cost of rebuilding.

If you are not sure what your current support covers, our guide to WordPress maintenance lists what a proper plan should include.

The Canadian angle: security is also a legal duty

Under PIPEDA, businesses must protect personal information with safeguards appropriate to its sensitivity, and they must report breaches that create a real risk of significant harm to the Office of the Privacy Commissioner of Canada. In Quebec, Law 25 adds its own obligation to report confidentiality incidents. A contact form full of names, emails and phone numbers counts as personal information.

Running software that no longer receives security fixes, on a site that collects customer data, makes it much harder to argue that your safeguards were reasonable if something goes wrong. This is not legal advice - for that, speak to a lawyer - but it is one more reason not to leave an end-of-life PHP version in place. Our overview of website privacy laws in Canada explains the main obligations.

If you can't upgrade before December 31

Sometimes a key plugin isn't ready, or the busy season gets in the way. If you have to run past the deadline, reduce the risk while you plan the upgrade:

• Put the site behind a web application firewall, such as the one Cloudflare offers.
• Keep WordPress core and every plugin as up to date as the old PHP version allows.
• Remove unused plugins and themes - every one is extra attack surface.
• Turn on two-factor authentication for all admin accounts and remove old users.
• Keep daily off-site backups.
• Ask your host whether it offers extended security support for 8.2, and put a date for the upgrade in the calendar.

More on the basics in our guide to website security: SSL, backups and updates.

When a PHP upgrade is a sign of something bigger

If moving to a supported PHP version breaks half the site, the PHP version is not the real problem. It is the symptom of years of technical debt: plugins nobody maintains, custom code nobody understands and a theme built for a different era. At that point, patching may cost more than starting fresh on a clean foundation.

That is not an automatic reason to rebuild, but it is a good moment to ask the question honestly. Our list of signs your website needs a redesign and our comparison of custom code and WordPress can help, and if you do rebuild, follow a migration checklist that protects your rankings.

Your PHP checklist for 2027

• Check your PHP version in Tools → Site Health → Info → Server.
• Ask your host what happens to PHP 8.2 sites after December 31, 2026.
• Take a backup and confirm you can restore it.
• Update WordPress, your theme and all plugins.
• Delete unused plugins and replace abandoned ones.
• Test PHP 8.4 on a staging copy, including forms and checkout.
• Switch the live site at a quiet time and monitor it for a week.
• Put PHP 8.4's end of support, December 31, 2028, in the calendar now.

Frequently asked questions

When does PHP 8.2 reach end of life?

PHP 8.2 reaches end of life on December 31, 2026. From January 1, 2027, the PHP project no longer releases security fixes for it. PHP 8.1 reached end of life a year earlier, on December 31, 2025, and PHP 8.3 follows on December 31, 2027.

Will my WordPress site stop working on January 1, 2027?

No. A site on PHP 8.2 keeps loading normally after the deadline. What stops is security patching: any vulnerability found in PHP 8.2 after that date stays unfixed. Over time, plugins and themes also drop support for old PHP versions, so you lose the ability to update them.

How do I check my PHP version in WordPress?

In the WordPress dashboard, go to Tools, then Site Health, open the Info tab and expand the Server section. The PHP version is listed there. You can also find it in your hosting control panel or by asking your hosting provider.

Which PHP version should I use for WordPress in 2027?

For most sites, PHP 8.4 is the best choice in 2027 because it receives security fixes until the end of 2028 and is widely supported by maintained plugins. PHP 8.3 works as a temporary step, and PHP 8.5 suits sites whose plugins all pass testing on it.

Can upgrading PHP break my website?

It can, usually because of an outdated plugin, an old theme or custom code that relies on behaviour newer PHP versions changed. That is why you should test on a staging copy first, check the error log, and keep the previous version ready to switch back to on the live site.

Does a newer PHP version make my site faster?

Often, yes. Newer PHP 8 releases include performance improvements, and many sites respond a little faster after upgrading from an old version. The gain varies from site to site, though, so treat speed as a bonus. The main reason to upgrade is security.