Check PHP Before a WordPress Core Update

WordPress core updates are generally safe to apply quickly — the project has a strong track record of backward compatibility. But a handful of updates each year raise the minimum PHP version or drop support for an older PHP that your host has not moved off. If you hit that combination without checking, you may be looking at a broken site.

This use-case walks through the two-tool check you should run before applying a WordPress core update in production. Cluster hub: WordPress.org Ops.

---

Why PHP and WordPress core are coupled

WordPress has a declared minimum PHP version in each release. When WordPress 6.4 shipped, it required PHP 7.0. When later versions moved to PHP 7.4 as the minimum, a site still running PHP 7.0 could no longer update. In practice, the WordPress project raises the minimum slowly and with long lead times — but hosting PHP tends to lag even further behind.

The serve-happy endpoint at WordPress.org is the official check: it tells you whether your PHP version is acceptable (will run WordPress), supported (php.net is still patching bugs), or secure (php.net is still patching security vulnerabilities). Failing any of these is a signal to act, even if your site currently works.

---

Before you start: find your PHP version

You need the exact PHP version your site runs. These are the most reliable sources:

phpinfo() — Create a temporary file in your web root:

<?php phpinfo(); ?>

Visit it in your browser. The PHP version appears at the top of the page. Delete this file immediately after — leaving it exposed is a security risk.

WP-CLI — If you have shell access:

wp --info

This outputs the PHP version used by WP-CLI. It is typically the same as the web PHP if they share the same interpreter.

php -v in a shell session — Accurate if the shell uses the same PHP binary as PHP-FPM or mod_php for your vhost. On some shared hosts, the CLI PHP and the web PHP are different versions. Check with your host if unsure.

cPanel or hosting panel — Look in “PHP Version” or “PHP Selector.” Note that panel defaults may not reflect a .htaccess or user.ini override for your specific domain.

---

Step 1: Run the PHP Version Checker

Open the PHP Version Checker and type your PHP version (e.g., 8.1 or 8.2).

The tool asks the WordPress.org serve-happy endpoint for the status of that version and returns:

• Recommended version — the PHP WordPress.org recommends for new installations
• Minimum version — the lowest PHP WordPress core currently accepts
• is_acceptable — will WordPress run on this PHP?
• is_supported — is php.net still releasing bug fixes for this version?
• is_secure — is php.net still releasing security patches?

The result shows a plain-language verdict: acceptable, aging, or not recommended.

If the verdict is “acceptable” — you are in the supported window. Proceed to step 2.

If the verdict is “aging” — your PHP is is_acceptable (WordPress will run) but it is past active support. It may still receive security patches, but bug fixes have stopped. This is not a blocker for the update, but it is a clear signal to upgrade PHP on your hosting plan. Note the recommended version and raise a ticket with your host.

If the verdict is “not recommended” — your PHP is below the minimum WordPress.org declares. Running WordPress on this PHP may still be technically possible on your current version, but updating core could break things. Do not apply the core update until you have upgraded PHP.

---

Step 2: Run the Core Version Checker

Open the Version Checker and enter your current WordPress version (visible in wp-admin Dashboard → At a Glance, or Dashboard → Updates).

The tool returns:

• The current WordPress.org release version
• A verdict: whether your version is current, outdated, or significantly behind
• The PHP and MySQL minimums for the current release

If your WordPress is current — you are on the latest release. The version check confirms there is nothing to update to right now.

If your WordPress is one minor version behind — apply the update. Minor versions are almost always security or maintenance fixes with no breaking changes.

If your WordPress is multiple major versions behind — the update path is still direct, but check the release notes for the major versions you are skipping. WordPress.org publishes release announcements at wordpress.org/news/. Look for notes about minimum PHP changes, deprecated functions, or database changes.

---

Step 3: Check must-have plugins

After confirming the core update is safe on your PHP, check the plugins your site cannot function without. A core update that is safe for WordPress itself may still conflict with a plugin that declares a higher requires_php.

For each critical plugin:

1. Open the Plugin Analyzer with the plugin slug.
2. Read requires_php in the Overview tab.
3. If any plugin requires a higher PHP than you are running, the plugin may deactivate after a plugin auto-update, even if the core update itself succeeds.

This step is most important for e-commerce sites (WooCommerce and its add-ons), membership sites, or sites running complex page builders. These ecosystems tend to move PHP requirements more aggressively than simpler plugins.

---

Step 4: Test on staging (for major updates)

For a point release (6.7.1 → 6.7.2), testing on staging is optional if your site is simple and you have done this update path before. For a major release (6.6 → 6.7), testing on staging is recommended.

A staging clone is a copy of your production database and files running on the same PHP version as production. Most managed hosts (WP Engine, Kinsta, SiteGround) have a one-click staging feature. For self-hosted, tools like WP Migrate DB Pro or the All-in-One WP Migration plugin can create a staging clone.

On staging:

1. Apply the core update.
2. Check the front end — homepage, key pages, checkout if applicable.
3. Check the back end — post editing, plugin settings, WooCommerce admin.
4. Check PHP error logs for deprecated function notices.

If staging passes, apply to production.

---

Step 5: Apply the update

In wp-admin → Dashboard → Updates, click Update Now. WordPress will:

1. Put the site in maintenance mode (shows a .maintenance file).
2. Download the new core files from WordPress.org.
3. Overwrite wp-admin/ and wp-includes/.
4. Run any database upgrades.
5. Remove the maintenance file.

The whole process takes 30–60 seconds on a typical hosting plan. If it takes more than 2 minutes or the maintenance mode does not clear, check the server error log — the most common cause is a file permission issue on wp-content/upgrade/.

---

If the update breaks something

PHP fatal error on the front end or admin — check the PHP error log. Fatal errors in a WordPress core file are rare after a clean update. A fatal error in a plugin or theme means that plugin or theme needs an update for the new core version.

White screen of death — usually a fatal PHP error. Enable WP_DEBUG temporarily in wp-config.php:

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

Then read wp-content/debug.log for the actual error message.

Plugin deactivated after update — the plugin’s requires_php was higher than your PHP, or the plugin has a runtime incompatibility. Update the plugin first; if it is not updated, check the support forum.

---

Related

• PHP Version Checker
• WordPress Version Checker
• PHP Version Checker guide
• Plugin Analyzer
• All WordPress.org Ops tools