Which PHP Version for 2027? 8.3, 8.4 or 8.5

For most WordPress sites, PHP 8.4 is the safest target for 2027. PHP 8.3 still gets security fixes until 31 December 2027, so it is fine for now but it has an end date inside the year, while PHP 8.5 is the longest runway if your host offers it and your plugins behave on it.

Here is the part most people miss: PHP 8.3 stopped getting ordinary bug fixes on 31 December 2025. If your site runs 8.3 today, it has been on security-only support since the start of 2026.

By the end of this guide you will know what those support dates mean, which version fits your site, and how to switch and confirm it worked.

What PHP support windows actually mean

PHP (the language WordPress is written in) is released in versions, and each version gets a fixed support life. The PHP project gives each one two years of active support, then two years of security-only support.

Active support means the PHP team fixes regular bugs and security problems. Security support means they only fix critical security problems.

Think of it like a warranty on a washing machine. For the first two years the full warranty covers anything that breaks. For the next two years you only get the safety recall cover: if something could catch fire they fix it, but a squeaky drum is your problem.

When security support ends, there is no cover at all. The version keeps running, but nobody upstream patches new holes in it.

Why this matters: a site on a version inside security support still gets fixes for critical PHP security flaws. A site past that date does not, even if everything looks fine on the surface.

If you are still on PHP 8.2, that is a more urgent job than this one. Read our PHP 8.2 end of life check and the PHP 8.2 upgrade guide first, then come back here.

Before you start

Gather these before you touch anything. It takes ten minutes and saves hours.

• Your current PHP version, which you can see in your hosting panel or in WordPress Site Health.
• Your WordPress version, since core support for newer PHP depends on it.
• A list of active plugins and your theme, with each one's update status.
• A fresh backup of files and database that you have confirmed you can restore.
• A staging copy of the site, meaning a private clone where you can test safely.
• Your hosting panel login, for example cPanel.
• A quiet time window of about an hour, outside your busiest traffic.

Quick tip: while you are checking versions, look at your database too. WordPress recommends MySQL 8.0 or MariaDB 10.11 or greater, and our MySQL version check walks through that.

The three versions compared

All dates below come from the official PHP supported versions page. At the time of writing (10 November 2026), these are the facts.

PHP 8.3

• Released 23 November 2023.
• Active support ended 31 December 2025.
• Security support until 31 December 2027.
• What it means for you: safe through 2027, but you will need to move again before the year ends. Treat it as a holding position, not a destination.

PHP 8.4

• Released 21 November 2024.
• Active support until 31 December 2026.
• Security support until 31 December 2028.
• What it means for you: on 1 January 2027 it moves from active to security-only support. That is not end of life. It keeps getting security fixes until the end of 2028, which gives a two year runway from now.

Heads up: you may see people online say PHP 8.4 "ends" in December 2026. Only the bug fix phase ends then. Security fixes continue until 31 December 2028.

PHP 8.5

• Released 20 November 2025.
• Active support until 31 December 2027.
• Security support until 31 December 2029.
• What it means for you: the longest support of the three, and the only one still in active support for all of 2027. It is also the newest, so some plugins may lag behind.

PHP 8.5 brings new things such as a built-in URI extension, the pipe operator, and the functions array_first() and array_last(). Those matter to developers more than site owners.

What matters to you is what it removed and deprecated. A deprecation is a warning that something still works but will be removed later. In 8.5 the disable_classes INI setting was removed, and the backtick operator, non-canonical casts such as (boolean) and (integer), and using null as an array offset were deprecated. The __sleep() and __wakeup() methods were soft-deprecated. Older plugin code that relies on these is where your warnings will come from.

What WordPress says about each version

WordPress keeps a PHP compatibility table for core, last updated 4 November 2026. It shows:

• PHP 8.3 is supported by WordPress 6.4 through 7.1.
• PHP 8.4 is supported from WordPress 6.7 onward.
• PHP 8.5 is supported from WordPress 6.9 onward.

So if your site is on WordPress 6.8, PHP 8.5 is off the table until you update core. If you are on 6.6, even 8.4 is not supported yet.

The official requirements page recommends PHP 8.3 or greater, and MySQL 8.0 or MariaDB 10.11 or greater. It also says WordPress still runs on PHP 7.4 and later and MySQL 5.5.5 and later in legacy setups, but those have reached end of life and may expose your site to security vulnerabilities.

Heads up: that table covers WordPress core only. Your plugins and theme are separate code written by other people, and any of them can break on a newer PHP even when core is happy.

WordPress 7.2 is scheduled for 8 December 2026, and it is in beta now. Beta builds must not run on production sites. If you want to try it alongside a PHP change, do it on staging, and our guide to testing WordPress 7.2 beta on staging covers how.

How to decide in 4 questions

Answer these in order. Stop at the first one that gives you a clear answer.

1. Is my WordPress core at least 6.9? If not, update core first. Below 6.9 you cannot use 8.5, and below 6.7 you cannot use 8.4.
2. Does my host offer PHP 8.5 in the panel? Availability depends on the server. If it is not in the menu, your choice is 8.4, and that is a perfectly good choice.
3. Do my key plugins and theme work on the version I want? Check each plugin's page and changelog, then test on staging. If anything important fails on 8.5, settle on 8.4.
4. Do I have a staging copy to test on? If not, make one before switching. If you truly cannot, move one step at a time, for example 8.3 to 8.4, rather than jumping two versions on a live site.

Here is a made-up example to show how it plays out. Example site: a small bakery shop at example.com, running WordPress 7.1, a page builder plugin, a booking plugin and a contact form, currently on PHP 8.3.

Question one passes, since 7.1 supports all three versions. The host shows 8.4 and 8.5 in the menu. On staging the site runs clean on 8.4, but the booking plugin throws deprecation warnings on 8.5 and its last update was eight months ago. Decision: move to 8.4 now, and revisit 8.5 in mid 2027 once the booking plugin catches up.

Why this matters: picking 8.4 here buys security fixes until the end of 2028 with zero broken features. Waiting on 8.3 would just mean doing this same job under pressure late in 2027.

If you decide to switch

Test on staging first. Always. Change the version on the staging copy, click through the site, and only then repeat on live.

Change the version in cPanel

In cPanel, open MultiPHP Manager, which sits in the Software section. Then:

1. Tick the checkbox next to the domain you want to change.
2. Open the PHP Version menu and choose the version.
3. Click Apply.

If PHP-FPM is enabled for the domain, the system updates the FPM version to match.

Heads up: if a domain is set to inherit, it simply follows the server default. cPanel will not let you enable PHP-FPM on a domain set to inherit, so pick an actual version if you want FPM.

Check plugins before and after

On each plugin's page in the WordPress.org directory, the sidebar shows a line such as "PHP version 7.2 or higher". That is the minimum the author requires, not a promise that the newest PHP works. Also read the plugin's changelog for mentions of PHP 8.4 or 8.5.

For premium plugins and themes, check the vendor's own site or ask their support directly.

How to check it worked

Run these checks right after switching.

• In your host panel, MultiPHP Manager should now show the new version next to the domain. Expected result: the version you picked, not the old one.
• In WordPress, go to Tools > Site Health > Info and open the Server section, where server and PHP details are listed. Expected result: the PHP details there match the version you chose.
• On the Status tab of Site Health, look for new critical items. Expected result: no new warnings about PHP.
• Click through key pages: home, a post, checkout or booking, the contact form, and the admin dashboard. Expected result: everything loads and submits as before.
• Check your error log for the next day or two. Expected result: no new fatal errors, and only a few deprecation notices at most.

Troubleshooting

A plugin crashes the site after the switch

Symptom: a blank page or a critical error message, often only on some pages. Likely cause: a plugin or theme uses code the new PHP no longer accepts. Fix: switch back to the previous version in MultiPHP Manager to restore the site, then update or replace the plugin and test again on staging.

The version I want is missing from the menu

Symptom: 8.5 (or 8.4) does not appear in the PHP Version menu. Likely cause: that version is either not installed on the server or not available for your account. Fix: ask your host. On cPanel servers an administrator installs PHP versions through EasyApache 4 in WHM.

Deprecation notices fill the log

Symptom: lines mentioning "Deprecated" appear in the log, but the site works. Likely cause: plugin code uses features that the new version has marked for future removal, such as the casts mentioned above. Fix: these are warnings, not failures. Send them to the plugin author and keep updating, and make sure errors are logged rather than shown to visitors.

To log errors on staging without showing them on the page, WordPress documents these settings in wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

The log lands in wp-content/debug.log. WordPress says these tools are meant for local and staging installs, so do not leave them on in production.

I cannot enable PHP-FPM

Symptom: the PHP-FPM option will not turn on for a domain. Likely cause: the domain is set to inherit. Fix: choose a specific PHP version for that domain first, then enable FPM.

Site Health still shows the old version

Symptom: you changed the version but WordPress reports the old one. Likely cause: you ticked a different domain or subdomain, or a cache is serving an old view. Fix: confirm the right domain changed in MultiPHP Manager, clear your caching plugin and any server cache, and reload Site Health.

Pro tips and when to ask for help

• Move one version at a time on busy or complex sites. Going from 8.3 to 8.4 is a smaller jump than 8.3 to 8.5.
• Put a reminder in your calendar for mid 2027 to review 8.5 again. Plugins catch up over time.
• Keep the old version noted down so you can roll back in seconds.
• Update plugins and themes before the switch, not after, so you test the newest versions.

Ask your host if the version you want is missing, if FPM settings confuse you, or if you are not sure which server default your account inherits. Ask a developer if a custom plugin or theme throws fatal errors, if the site has code nobody maintains anymore, or if a store or booking system is involved and downtime costs money.

The one message worth forwarding

Copy this and send it to your developer or host:

Hi, we want to move example.com from PHP 8.3 to a version with longer security support for 2027. Could you please: 1) confirm which PHP versions (8.4, 8.5) are available for our account, 2) create or refresh a staging copy, 3) test the site on PHP 8.4 and on 8.5 if available, including our plugins and theme, 4) share any fatal errors or deprecation notices from the log, and 5) switch the live site to the version that tests clean, with a rollback plan. Our quiet window is weekdays after 10 pm. Thanks.

Pick the newest PHP version your host offers and your plugins pass on staging, and for most sites in 2027 that means at least PHP 8.4.