How to Update PHP Version on WordPress Site Before Dec 31

Your WordPress site runs on PHP, the programming language WordPress is written in. On December 31, 2026, the PHP project ends security support for PHP 8.2 — and a site still running it enters 2027 on an unsupported engine. This guide shows how to update PHP version on WordPress site hosting safely: check, back up, test, and switch before the deadline.

What Actually Ends on December 31

PHP gives every release branch two years of active support, then two years of security-only support. After that, the branch reaches end of life and receives no more fixes. Per PHP’s own supported-versions page, PHP 8.2 — first released December 8, 2022 — reaches the end of its security support on December 31, 2026.

PHP versionSecurity support endsStatus after Dec 31, 2026
8.2Dec 31, 2026End of life
8.3Dec 31, 2027Supported
8.4Dec 31, 2028Supported
8.5Dec 31, 2029Supported

“End of life” does not mean your site shuts off at midnight — your pages will still load on January 1 as they did the day before. What disappears is the safety net: when the next flaw turns up, the fix goes into 8.3, 8.4, 8.5, and 8.6 — nothing is backported to 8.2.

The scale of the exposure is large. SSL Dragon’s October 8 warning, citing WordPress.org statistics from October 6, found 36% of WordPress sites already on PHP versions that had lost support, plus 25% still on PHP 8.2 — meaning 61% will run unsupported PHP on January 1, 2027 unless they upgrade. A separate WordPress.org statistics API analysis (September 5 snapshot) found 57.6%. The exact figure depends on the snapshot; the direction does not.

Two more facts: between March 2025 and September 2026, the PHP project issued seven security releases for PHP 8.2 fixing 34 flaws. And PHP 7.4, unsupported since November 28, 2022, was still on 17% of WordPress sites in the October 6 snapshot. Sites that miss this deadline tend to stay behind for years. SSL Dragon sells security products, so treat its release as vendor-issued; the numbers come from WordPress.org and PHP’s own calendar.

Why This Deadline Is Harder Than It Looks

Three things collide in the same few weeks — book the upgrade now, not “someday.”

First, the holidays. Adobe expects US online holiday sales of $275.1 billion between November 1 and December 31, 2026, per the same release — the worst window for an unplanned outage. Cyber Week runs Thursday, November 26 (Thanksgiving) through Cyber Monday, November 30, 2026. Skip Cyber Week; switch in the next few weeks, while traffic is ordinary.

Second, WordPress 7.2 is due December 8, 2026 (betas from October 20), per the release schedule. A core update and a PHP switch in the same month is two variables at once: do PHP first, then the core update. Third, PHP 8.6 arrives November 19, 2026 — but a brand-new branch is the wrong target for production before plugin authors certify against it. Aim for 8.3 or 8.4.

Which PHP Version Should You Switch To?

WordPress.org’s requirements page recommends PHP 8.3 or greater; the Hosting Handbook recommends PHP 8.4 or later for production. WordPress 6.8 and later fully support PHP 8.4, and 6.9 and later fully support PHP 8.5 (the core team retired the old “beta support” label in May 2026). The remaining compatibility risk is your plugins and theme, not core.

  • PHP 8.4 — the sensible default. Security fixes through December 31, 2028, the Hosting Handbook’s production recommendation, nearly two years of ecosystem testing.
  • PHP 8.3 — the conservative choice. Matches WordPress.org’s recommendation, supported through December 31, 2027. Pick it for the smallest jump.
  • PHP 8.5 — only if your plugins confirm support. Supported through December 31, 2029. Check each plugin’s and your theme’s requirements first.

Do not pick 8.2 — that just reschedules the same job for next December.

How to update PHP version on WordPress site — server racks in a data center running the PHP version behind a WordPress site

Before You Touch Anything: Prerequisites

A PHP upgrade is a hosting change, not a dashboard change: updating a plugin or clicking “Update WordPress” does not change the PHP version. The version lives on the server, changed in your hosting panel. The steps below run in order.

1. Make a full backup — and confirm you can restore it. Back up files and database with your host’s backup tool or a plugin. An untested backup only proves the backup job ran — it proves nothing about the restore. As SSL Dragon’s Roman Munteanu put it: “A backup you’ve tested makes the upgrade a small enough risk to take before December 31.”

2. Update WordPress core, your theme, and all plugins first. Outdated code is the top reason a PHP switch breaks something. Update your plugins safely before the PHP change, not after — that way, if something breaks, you know the PHP switch caused it. Keep WordPress core current (7.1.3 as of this writing).

3. Inventory the risky pieces. Note any plugin or theme that is abandoned (no update in over a year), custom-coded, or flagged in Site Health — the items most likely to trip on newer PHP. Check the developer’s site for a compatibility statement, or plan to replace it.

4. Use staging if your host offers it. A staging copy lets you flip the PHP version with zero risk to live visitors. Without staging, pick a low-traffic hour and keep the rollback steps below within reach.

How to update PHP version on WordPress site — external hard drive beside a laptop for backing up a WordPress site before a PHP update

How to Update PHP Version on WordPress Site (Step by Step)

Step 1: Check your current PHP version

In your dashboard, go to Tools → Site Health → Info, then scroll to Server. Your PHP version is listed there. If it reads 8.3, 8.4, or 8.5, you are fine — just remember the dates in the table above. If it reads 8.2, schedule the upgrade now. If it reads 8.1 or lower, the upgrade is already overdue: that branch receives no fixes. Do not rely on the absence of a dashboard warning — check the number against the PHP calendar.

Step 2: Switch PHP in your hosting panel

The clicks depend on your host, but the pattern is the same: hosting account → PHP settings → pick the new version → save.

  • Hostinger (hPanel): go to Advanced → PHP Configuration, choose the version, and click Update.
  • cPanel hosts: go to Software → Select PHP Version (or MultiPHP Manager), pick the version for your domain, and click Set as current or Apply.
  • Other hosts: look for “PHP Version Manager” or “PHP Selector.” With no PHP selector, open a support ticket asking to move your account to PHP 8.4 — a normal request.

The change usually takes effect within minutes. Your files, database, and content are untouched; only the engine running them changes.

Step 3: Verify and test after the switch

Reload Tools → Site Health → Info → Server and confirm the new PHP version. Clear your site cache (plugin plus host cache) so you test the new runtime, not a stale page. Click through the pages that matter: homepage, a blog post, your contact or checkout page, and the login screen. Submit one test form or order. Check Site Health’s Status tab, and watch the site for 24 hours.

If Something Breaks: Rollback in Minutes

WordPress’s own guidance is candid: the change “should not be a problem, but we can’t guarantee that it’s not.” That is why the backup and staging steps come first.

If you hit a white screen or fatal errors, switch PHP back in the same hosting panel. This alone fixes most failures. If the site is still broken, restore the backup from the prerequisites. Then diagnose on staging: reactivate plugins one at a time, switch briefly to a default theme, and check the error log for the exact file and line. Replace or update the offending piece before trying again. Do not “fix” a broken switch by editing PHP files on the live site to silence errors — hiding an error is not resolving it.

Common Mistakes to Avoid

  • Waiting until December. The deadline collides with holiday traffic, Cyber Week, and WordPress 7.2. Early November at the latest.
  • Upgrading PHP and core on the same day. Change one variable at a time.
  • Skipping the backup because “it’s just a dropdown.” The dropdown is safe; your untested 2019 plugin is the risk.
  • Jumping to PHP 8.6 on day one. Let plugin authors certify against it first.
  • Assuming your host will handle it. Some do; many do not. Check your version in Site Health.

Frequently Asked Questions

What happens if I stay on PHP 8.2 after December 31, 2026?

Your site keeps running — nothing breaks on January 1. What stops is the flow of security fixes: when new PHP flaws are found, patches go to supported branches only. Over time, unpatched issues stack up. Some hosts backport critical fixes for a while, but that is their choice, not a guarantee.

Which PHP version should I switch to — 8.3, 8.4, or 8.5?

For most sites, PHP 8.4 is the sensible default: the Hosting Handbook’s production recommendation, with security fixes through December 31, 2028. PHP 8.3 is the conservative choice, matching WordPress.org’s recommendation, supported through December 31, 2027. Choose 8.5 only if your theme and plugins confirm support.

Will updating PHP break my WordPress site?

Usually, no — if you back up, update everything first, and test on staging. Most failures come from an outdated or abandoned plugin, and the rollback is fast: switch PHP back in your hosting panel, then fix or replace the offending plugin on staging.

Can I update PHP from the WordPress dashboard?

No. The dashboard updates core, themes, and plugins — it cannot change the PHP engine that runs them. PHP is set by your hosting provider in the control panel (for example, Hostinger’s Advanced → PHP Configuration, or cPanel’s Select PHP Version). Without a PHP selector, ask support to move your account to a supported version.

Conclusion

PHP 8.2’s security support ends December 31, 2026, and roughly 6 in 10 WordPress sites will run unsupported PHP on January 1 unless they act. The fix is small and reversible: check Site Health, back up, update everything, switch PHP to 8.4 (or 8.3) in your hosting panel, and test — before Cyber Week, not during it. Start by opening Tools → Site Health → Info → Server and noting the number.

Sources (last checked October 17, 2026)

Was this article helpful?

Leave a Comment