Sébastien Laframboise

Check the PHP version WordPress is using before changing it

Check the PHP version WordPress is using before changing it

Changing the WordPress PHP version can improve security, stability and sometimes performance. However, PHP runs the core of WordPress, themes and plugins. An incompatibility can therefore cause a critical error, a white screen, or a feature that stops responding.

The right approach is to check the version actually used by the site, prepare a rollback, and test the change in a structured way. This avoids changing a server setting blindly.

Why check the WordPress PHP version before making any change?

PHP is the language that runs WordPress on your hosting. Its version and configuration therefore affect the site’s operation. The advanced WordPress administration manual on PHP reminds that a recent version brings fixes, improvements and changes that are not always backwards compatible with older code.

WordPress currently recommends PHP 8.3 or a newer version. It may still run on PHP 7.4, but that version has reached end of life. The table of official WordPress requirements clearly distinguishes the minimum required to run from the baseline recommended for security and performance.

However, you shouldn’t automatically choose the highest version offered by your host. Instead, start by determining what your theme, plugins and integrations actually support. This precaution is especially important for a store, a form, a booking system or a members area.

Find the PHP version actually in use

Your host’s control panel sometimes shows a general PHP version for the account. A subdomain, directory or specific site may use a different setting. First rely on the value WordPress detects itself.

Use Site Health in WordPress

  1. Log in to the WordPress admin.
  2. Open Tools > Site Health.
  3. Choose the tab Info.
  4. Open the section Server.
  5. Locate the line PHP version and note it.

The documentation for Site Health indicates that the Server section lists information related to the server configuration, including several PHP variables. Then compare that value with the one in your host’s dashboard.

If the two values differ, do not proceed with the upgrade. Instead ask the host which rule applies to the domain. It might be a per-site, per-directory, or per-environment setting. Your goal is to change the version that WordPress is actually running.

Choose a realistic, supported target

A PHP version that’s still supported receives patches according to its maintenance cycle. The official PHP support schedule for PHP versions specifies that a branch first gets active support, then security fixes for a limited period.

As of September 2026, PHP 8.2 still receives security fixes through 31 December 2026. PHP 8.3, 8.4 and 8.5 are also supported under that schedule. However, WordPress recommends PHP 8.3 or newer. That target is therefore a good starting point, provided your components are compatible.

Avoid jumping recklessly from a very old version to the newest. If your site contains poorly maintained plugins or custom code, plan the change more cautiously. In that case, upgrading to a compatible, supported version may be preferable to a rushed migration.

Check compatibility before changing

Update site components

Before changing PHP, update WordPress, plugins and the active theme. This step reduces the risks posed by outdated code. For WordPress core, follow a guided approach in updating WordPress without breaking your site.

Next, review each important plugin. Check its official page, changelog and documentation. Pay special attention to plugins that handle payments, forms, email, caching, security, or connections to external services.

Do the same for the active theme and its child theme, if any. Custom code in a theme, a homemade plugin or a mu-plugin deserves a separate review. An abandoned component increases the risk of conflict; if needed, plan to replace it before changing PHP.

Prepare a backup and a real rollback plan

Create a a full backup just before the change. It must include the site files and the database. To arrange this protection, see how to create a reliable automatic WordPress backup.

A copy exists only to be restored. So verify in advance how to return to the previous PHP version in the host panel. Also confirm that the old version remains available during your tests. Finally, if your business depends on the site, make sure you know how to restore the backup in a controlled environment. The guide to testing a WordPress backup restore helps you validate this essential step.

Perform the PHP upgrade in a controlled way

Ideally, first test the change on a development or staging copy. Use a recent copy with the same plugins, the same theme, and settings similar to the live site. That way you can spot a conflict without interrupting your visitors.

If you must work directly on the live site, pick a quiet period. Note the time, the current PHP version, and the new version you choose. Change only that setting, then reload the site and the WordPress admin.

Post-change checklist

  • Open the homepage and several important pages in a private window.
  • Check the menu, search, images, and internal links.
  • Log into the admin and create a test draft.
  • Submit a form and confirm receipt of the expected email.
  • Test the cart, checkout, and transactional emails if your site sells online.
  • Check the error logs provided by the host.
  • Return to Site Health to confirm the new PHP version detected by WordPress.

A visible error or a log entry doesn’t always mean the whole site is lost. Disable or update the affected component on your test environment. If the live site stops working, revert quickly to the previous PHP version, then analyze the conflict without pressure.

Mistakes to avoid

  • Changing PHP without a recent, accessible backup.
  • Relying only on the version shown in the hosting account.
  • Changing PHP at the same time as WordPress, the theme, and multiple plugins.
  • Testing only the homepage after the change.
  • Leaving an unmaintained plugin to indefinitely block a necessary upgrade.

In short, first check the PHP version detected by WordPress, prepare your backups, update your components, and test the chosen target. This approach turns a risky server change into a predictable maintenance operation.