How do I find out which PHP version my site uses?

In the WordPress backend under Tools → Site Health, on the Info tab, in the Server section. Your hosting panel shows it too, often under PHP settings. From a terminal, `wp --info` reports the command-line version, which can differ from the web PHP.

Can a PHP update take my site down?

Yes, if a plugin or theme contains code the new version no longer understands. That leads to a critical error or a white screen. So you test on a staging copy first and keep a backup and the way back in the hosting panel ready.

What is the difference between deprecation notices and fatal errors?

A deprecation notice says code will stop working in a later PHP version, but the site keeps running. A fatal error stops execution, for example when a removed function like create_function() is called. Deprecations are a to-do item, fatal errors are a reason to roll back.

Can I go back to the old PHP version after updating?

With most hosts, yes, usually with one click in the panel. That is your way out if something breaks on the live site. Check that option beforehand rather than in an emergency, and write down the previous version.

Do I need to update WordPress or plugins after the PHP update?

Not necessarily, but update plugins and theme before you switch PHP, since vendors usually fix compatibility problems through updates. Read the changelogs for notes on PHP 8.x.

Does the PHP version also apply to cron jobs and WP-CLI?

Not automatically. The command line often uses its own PHP binary, which can differ from the web version. Check with `php -v` and `wp --info` which version cron jobs and scripts actually use.

Updating the PHP Version in WordPress – Without Breaking the Site

Q: Which PHP version should WordPress use in 2026?

PHP 8.4 is the sensible default: actively supported, with security updates until the end of 2028. The WordPress requirements page currently recommends PHP 8.3 or greater, and PHP 8.5 is the newest release. Replace anything below 8.2 soon, as it no longer receives security updates.

PHP is the engine under your WordPress site. An outdated version is a double risk: no more security updates and less speed. According to the supported-versions page on php.net, PHP 8.1 reached end of life on 31 Dec 2025, and PHP 8.2 only receives security updates until the end of 2026. Anyone still on 7.x is running the site with holes nobody patches anymore. With the right process, the migration is very manageable.

First: Which Version Is Even Running?

Before you change anything, check the current state. There are several ways, and they do not always agree.

In the backend. Go to Tools → Site Health, open the Info tab and expand the Server section. It shows the PHP version WordPress is served with in the browser. If WordPress shows a warning about an outdated PHP version, the need to act is clear anyway.

In the hosting panel. Usually under “PHP settings” or “PHP version”. That is also where you switch later.

With phpinfo. A file containing <?php phpinfo(); in the web root shows the version, loaded extensions and the php.ini in use. This helps when panel and backend contradict each other. Delete the file right after you open it, because it reveals server details nobody else should see.

With WP-CLI. wp --info lists “PHP binary”, “PHP version” and the “php.ini used”, among other things. Note that this is the command-line PHP, not necessarily the web server’s. More on that below.

Which Version in 2026?

The php.net overview currently lists these dates:

PHP 8.2: security updates until 31 Dec 2026. Running out, do not pick it for new setups.
PHP 8.3: security updates until 31 Dec 2027.
PHP 8.4: actively supported until 31 Dec 2026, security updates until 31 Dec 2028.
PHP 8.5: released November 2025, actively supported until 31 Dec 2027, security updates until 31 Dec 2029.

The WordPress requirements page currently recommends PHP 8.3 or greater. The core team also maintains a compatibility table in which current WordPress versions are listed as compatible with PHP 8.0 through 8.5. So the core itself rarely causes trouble.

Our default is PHP 8.4: long runway, widely tested. PHP 8.5 is a fine choice if you know your plugins and theme well. If your setup depends on many third-party plugins, 8.4 is the calmer path. PHP 8.3 works as a cautious stopgap, but you only postpone the next migration by a year.

On speed: newer PHP versions are generally faster than older ones. How much that matters for you depends on plugins, caching and hosting, so I deliberately give no blanket percentage. The real reason to update is security anyway: only supported versions get patched.

Check Compatibility Before You Switch

Most of the risk sits not in the core but in plugins, themes and custom code. Three things help beforehand.

Read the changelogs. Check each plugin’s and theme’s changelog and plugin page. Notes like “PHP 8.4 compatibility” or “tested up to” are useful but no guarantee. A plugin that has not seen an update in years is the first candidate for replacement.

Update first. Bring plugins and theme to their latest versions before switching PHP. Compatibility fixes almost always arrive as updates. How to do that cleanly is covered in updating WordPress safely with staging.

Scan custom code statically. For your own themes, child themes and custom plugins there is PHPCompatibility, a ruleset for PHP_CodeSniffer. It checks source code for constructs that were removed or deprecated in particular PHP versions. According to its repository it aims to cover all changes since PHP 5.0 up to the latest release, and it is actively developed. After installing it via Composer:

vendor/bin/phpcs -ps . --standard=PHPCompatibility --runtime-set testVersion 8.4

It finds syntax and function problems, but not runtime errors that only occur with certain data. The click-through on staging stays mandatory.

How to Migrate Safely

Never switch directly on the live site. The process we use:

Back up files and database, and make sure you can actually restore it.
Create a staging copy and switch it to the new PHP version there.
Turn on error logging (next section) and click through the site: home page, forms, login, search, cart and checkout if present, plus any page with sliders or builder elements.
Fix issues: update incompatible plugins or replace them with maintained alternatives.
Check cron jobs (see below).
Switch live. Pick a low-traffic moment when you can watch the site for a few minutes afterwards.
Keep a rollback ready: note the old version beforehand. If a problem appears, such as a 500 error or a white screen, switch back in the panel until the cause is clear.

Make Errors Visible: Using WP_DEBUG Safely

So you do not hear about problems from visitors first, enable logging on staging. The WordPress developer documentation recommends this combination in wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

WP_DEBUG_LOG writes to wp-content/debug.log by default. WP_DEBUG_DISPLAY set to false keeps messages out of the page HTML. The same documentation states explicitly that the debug tools are meant for local testing and staging, not live sites. If you must log on the live site, do it only for the duration of the investigation, with display off, and delete the log file afterwards, since it can contain paths and other internals. Also check whether debug.log is reachable from outside, and switch the constants off again.

Typical Failure Patterns After the Switch

What matters is the difference between a warning and an abort.

Deprecation notices. They say: this works today, soon it will not. The site keeps running. Three examples from the PHP migration guides:

Since PHP 8.1, passing null to non-nullable parameters of built-in functions is deprecated. The guide uses str_contains("foobar", null) as an example. In WordPress logs, older plugins produce a lot of noise this way.
Since PHP 8.2, creating dynamic properties is deprecated unless the class uses the #[\AllowDynamicProperties] attribute. stdClass is exempt. The clean fix is declaring the property.
Since PHP 8.4, a typed parameter with a null default, T $x = null, is deprecated as implicitly nullable. The fix is ?T $x = null.

Deprecations are a to-do for the plugin author or your agency, not a reason to roll back.

Fatal errors. Here PHP stops. Examples from the PHP 8.0 migration guide:

create_function() and each() were removed. Old code that uses them ends in a fatal error.
The curly-brace string offset syntax, $string{0}, was removed.
count() on a non-countable value such as null throws a TypeError.
Arithmetic on arrays or objects throws a TypeError.

PHP 8.0 also changed comparisons between numbers and non-numeric strings: 0 == "foo" is now false. That throws no error but can quietly change logic. You only find cases like this by clicking through.

WordPress shows its critical-error page for such failures. How to proceed then is in fixing the critical error and using recovery mode.

The Recovery Mode Email

When a plugin or theme triggers a fatal error, WordPress sends an email to the admin address with a secret link. The link takes you into recovery mode, where the faulty extension is paused only for your browser. Other visitors still see the broken site. You can log in and deactivate or update the plugin. Check beforehand that the admin email address is correct and that mail actually arrives. Otherwise you only learn about the error from visitors.

CLI PHP and Web PHP Can Differ

The hosting panel often switches only the web server’s version. Cron jobs run from the command line may use a different PHP binary with a different version. This affects:

system cron jobs calling wp cron event run or your own PHP scripts,
deployment and maintenance scripts,
backup scripts that use PHP.

So run php -v and wp --info in the terminal. If the version differs from the backend, put the path to the matching PHP binary in your cron entries. Which binaries your host provides is in its documentation.

Switching at Your Host

Most hosts offer a selection in the customer panel, per domain or per web space. Some set the version through a handler in .htaccess. Your host dictates the exact line, so copy it only from their documentation, because a wrong handler causes a 500 error. After switching, clear caches (page cache, and OPcache if your host offers that) and reload front end and backend.

Rollback Plan

A rollback is not an admission of failure, it is part of the plan:

Note the current version before the switch.
Verify your backup.
On errors, first set the PHP version back in the panel, then analyse the cause on staging.
Read the log, fix the cause, test again.

If data changed after the switch, such as orders in a shop, restoring the backup is no longer straightforward. In that case, switching the PHP version back is enough, not the backup.

The Most Common Pitfall

Problems almost never come from the WordPress core, but from old plugins and themes. The longer an install has grown, the higher the risk. Typical symptoms after a too-hasty switch are individual features failing (a form, a slider) or the hard error. That is why the click-through on staging is not optional.

It is also the reason not to postpone a PHP migration forever: the bigger the version jump, the more technical debt you resolve at once. Anyone who updates in small steps, as part of any good WordPress maintenance, never faces a risky giant leap.

Want to move to PHP 8.4 without anything breaking? Drop us a line. We migrate via staging, check compatibility and keep the rollback ready.