How to Update PHP Without Breaking WordPress

Why update PHP

PHP runs WordPress, its plugins, and the theme on the server. Using a modern version usually brings security fixes, performance improvements, compatibility with current WordPress, and support from plugin and theme developers.

WordPress currently recommends PHP 8.3 or higher. Still, you shouldn’t switch versions without first checking that the theme, plugins, and custom code are compatible — the “newest version available” isn’t always right for a specific site on the day it’s released. For the general procedure to switch versions from the panel, see how to update your website’s PHP version; this article focuses on doing it without breaking WordPress.

Before you start

You need access to the hosting panel, a full backup of files and database (see WordPress backup and restore), to know the current version, the ability to temporarily roll back, access to error logs, and, for critical sites, a staging environment. Don’t make the switch right before a campaign, event, or busy sales period.

Step 1: check the current version

In WordPress, go to Tools > Site Health > Info > Server and check the PHP version, or check it with WP-CLI (see managing WordPress with WP-CLI): wp --info. Keep in mind the console’s PHP can differ from the one serving the site.

Step 2: check the requirements

Review the requirements of your current WordPress version, the active theme’s compatibility, every plugin’s compatibility, any child-theme or custom-plugin code, and the required PHP extensions (GD, Imagick, Intl, ZIP, SOAP, mbstring). Don’t just assume “the plugin is up to date” — check its requirements and release notes.

Step 3: update WordPress, plugins, and themes first

Before switching PHP, back up, update WordPress, the plugins, and the parent theme, review the child theme, remove abandoned components, and confirm the site works on the current PHP version. Updating everything at once makes it hard to know which change caused an error — do it in groups and verify.

Step 4: create a restorable backup

The backup should include the database, wp-content, wp-config.php, .htaccess, and the current PHP settings documented (previous version, memory_limit, upload_max_filesize, post_max_size, max_execution_time, any special extensions). Download a copy off the server and confirm it can be opened.

Step 5: test in a staging environment

Create a copy of the site on a subdomain or a protected staging environment. On the copy, switch PHP, open the homepage, log into /wp-admin, edit and save content, test forms, check search, test the store, run scheduled tasks, and check error_log. Make sure the staging environment doesn’t send real emails or process payments.

Step 6: turn on logging without showing errors

Before the production switch, turn on debug logging (see how to turn on debug mode):

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

Messages will be saved to wp-content/debug.log. Don’t leave debugging on indefinitely.

Step 7: switch PHP from the panel

In DirectAdmin, look for options like Select PHP Version or PHP Version Selector, select the domain, choose the compatible version, and save. In cPanel, look for MultiPHP Manager or Select PHP Version, tick the domain, choose the version, and click Apply. Don’t confuse the version selector with the PHP directives editor.

Step 8: review the PHP settings

When switching versions, some panels load a different configuration. Check memory_limit, upload_max_filesize, post_max_size, max_execution_time, max_input_time, and max_input_vars, plus the required extensions. Don’t raise values without a real need.

Step 9: check the site immediately

As both an anonymous visitor and an admin, check the homepage, internal pages, posts, menus, search, forms, the media library, the editor, login, the store, the REST API, cron tasks, and email. Clear caches after the switch to avoid stale responses generated under the previous version.

Step 10: review the logs

Look for PHP Fatal error, Deprecated, Warning, TypeError, or Uncaught Error. A Deprecated notice doesn’t always break the site, but it flags code that needs updating; a Fatal error or TypeError needs fixing before you consider the switch done. Identify the path: wp-content/plugins/ (plugin), wp-content/themes/ (theme), or a custom file (your own code).

Step 11: roll back if a serious error appears

If the site becomes unreachable, switch back to the previous PHP version from the panel, clear caches, confirm the service recovers, save the log message, and identify the incompatible plugin, theme, or code before repeating the test in staging. Rolling back is a temporary measure, not a permanent fix.

How to isolate an incompatible plugin or theme

If the error mentions a plugin, rename its folder inside wp-content/plugins (see how to deactivate WordPress plugins without admin access), look for an update, or contact its developer. If it’s the theme, temporarily activate a default one, review functions.php, and compare any overridden templates. Don’t edit the parent theme directly to “fix” it, since you’ll lose the changes on the next update.

Updating PHP in stages

If you’re on a very old version, it may be better to move up in stages: update WordPress and extensions, test a compatible intermediate version, fix errors, and move on to the target version, repeating the tests at each step.

Common issues

The site shows a white screen

Check the logs, deactivate the flagged plugin or theme, and temporarily roll back to the previous PHP version (see WordPress 500 error and white screen).

A 500 error shows up

Check .htaccess, incompatible PHP directives, and extensions. php_value lines can fail under PHP-FPM.

WordPress still shows the old version

Clear the cache, confirm you’re checking the right domain, and check whether the change applied to the subdomain or folder you’re actually visiting.

Frequently asked questions

Which PHP version should I choose?

One supported by WordPress, your theme, and your plugins. WordPress currently recommends PHP 8.3 or higher, but your specific site’s compatibility comes first.

Does updating PHP delete data?

It shouldn’t. It changes the execution environment, not the content, but an error can leave the site unreachable, which is why you need a backup and a rollback plan.

Can I update directly in production?

It’s possible, but not recommended for critical sites. Test in staging first.

Does a newer version always speed up WordPress?

It can improve performance, but it doesn’t fix slow queries, heavy images, or broken plugins (see 15 ways to speed up WordPress).

Conclusion

Updating PHP safely means knowing your current version, updating WordPress and extensions, backing up, testing compatibility, and keeping a rollback plan. If an old site depends on unmaintained code, don’t put off the update indefinitely — it may be better to fix or replace that component and keep your hosting on a modern, secure version.