WordPress and PHP Versions in Late 2026: What Core Supports and How to Upgrade Safely

Choosing a PHP version for a WordPress site comes down to three questions: which versions WordPress core supports, which version the project recommends, and which versions your plugins and theme actually work on. The first two have clear official answers; the third you have to test. This guide summarises the official position as of late October 2026 and gives a practical upgrade routine.

Where WordPress stands now

The current release is WordPress 7.1.4, a security release published on 28 October 2026; WordPress 7.2 is in beta. The requirements page recommends PHP 8.3 or greater, MariaDB 10.11 or MySQL 8.0 or greater, and HTTPS. It adds that WordPress still works on PHP 7.4 in legacy environments, but that such versions have reached end of life and may expose a site to security vulnerabilities.

The core team's compatibility table lists these ranges for recent releases:

Three recent changes explain the table. WordPress 6.9 added support for PHP 8.5. WordPress 7.0 dropped PHP 7.2 and 7.3, making 7.4.0 the minimum; sites still on those PHP versions stay on the 6.9 branch, and the project notes that only one branch officially receives security updates. And in May 2026 the project retired its "beta support" label, so every version in the table is simply listed as supported. The core team says there is no fixed schedule for raising the minimum again; it watches usage statistics instead.

Which PHP version to choose

Combine WordPress's recommendation with PHP's own support calendar from php.net:

• PHP 8.2 receives security fixes only until 31 December 2026. A site on 8.2 should be planning its move now.
• PHP 8.3 is security-only until 31 December 2027 and matches WordPress's recommended minimum.
• PHP 8.4 has security support until 31 December 2028 and is the version Debian 13 (trixie) ships.
• PHP 8.5 has security support until 31 December 2029; core supports it from WordPress 6.9, but check your plugins carefully before using it.
• PHP 8.1 and older are end of life upstream. WordPress may still run, but PHP itself no longer gets fixes from php.net.

For most production sites in late 2026, 8.3 or 8.4 is the practical choice: inside WordPress's recommendation, supported upstream for at least another year, and widely tested by plugin authors.

Core is only part of the picture

The compatibility page itself notes that WordPress is rarely used without themes and plugins, and core's table says nothing about them. Check three things for every active plugin and theme:

• Requires PHP. Plugins declare a minimum PHP version in the header of their main PHP file (since WordPress 5.8 this is read from the main file, not from readme.txt); themes declare it in style.css. It is a minimum only: a plugin that says Requires PHP: 7.4 can still break on 8.5.
• Recent updates. A plugin or theme with no release for a long time is the usual source of trouble after a PHP upgrade. Read changelogs for mentions of the PHP version you are moving to.
• Custom code. Child themes, must-use plugins and snippets added by past developers are tested by nobody but you.

Check what you run today

In the dashboard, Tools > Site Health shows a warning when the site runs an outdated PHP version, and the Info tab lists the server's PHP details. On the server, remember that the command line can use a different PHP from the website:

wp cli info          # PHP binary and php.ini used by WP-CLI (often not the web one)
php -v
ls /run/php/         # PHP-FPM sockets in use

For the definitive answer, check the version from inside a web request (Site Health does this for you).

Test the switch on a staging copy

1. Back up files and database, and confirm you can restore them.
2. Clone to staging on the same server or an identical one, with the same PHP extensions installed for the new version.
3. Update first: WordPress core, plugins and themes, still on the old PHP.
4. Turn on logging, not display, in staging's wp-config.php, above the line that says to stop editing:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/var/www/staging/logs/wp-debug.log' );
define( 'WP_DEBUG_DISPLAY', false );

Setting WP_DEBUG_LOG to a path outside the web root keeps the log from being downloadable; with true it is written to wp-content/debug.log.

5. Switch staging to the new PHP version (with PHP-FPM, point the site at the new version's pool) and walk through the flows that matter: login, forms, checkout and payment callbacks, search, image uploads, scheduled tasks.
6. Read the log. Fatal errors must be fixed before going live. Deprecation notices are warnings about future versions; note them and raise them with the plugin author.
7. Switch production at a quiet time and keep the old PHP pool for a few days so rollback is one configuration change.
8. Turn debugging off on staging when done, or remove the staging copy.

Common pitfalls

• Missing extensions for the new version: on Debian and Ubuntu every PHP version has its own extension packages, such as php8.4-intl or php8.4-imagick.
• Leaving WP_DEBUG_DISPLAY or PHP's display_errors on in production, which prints paths and errors to visitors.
• Testing only the home page. Most breakage after a PHP change shows up in admin screens, checkout and background tasks.
• Upgrading PHP on a site whose WordPress is several major versions behind. Update WordPress first.

What you should do

1. Note each site's WordPress and PHP versions from Site Health.
2. Move any site on PHP 8.2 or older to 8.3 or 8.4 before the end of 2026.
3. Check the Requires PHP header and recent update history of every active plugin and theme.
4. Test the new PHP version on staging with logging enabled, then switch production with a rollback path ready.
5. Keep WordPress itself on the current 7.1.x release; recent point releases are security releases.

If your site is on Skyline web hosting, websites and databases are backed up nightly and kept for 30 days with one-click restore; still take a fresh backup right before you switch PHP versions.

Sources

• make.wordpress.org/core/handbook/references/php-compatibility-and-wordpress-versions
• wordpress.org/about/requirements
• make.wordpress.org/core/2026/01/09/dropping-support-for-php-7-2-and-7-3
• wordpress.org/news/category/releases
• php.net/supported-versions.php
• php.net/eol.php
• developer.wordpress.org/plugins/plugin-basics/header-requirements
• developer.wordpress.org/plugins/wordpress-org/how-your-readme-txt-works
• developer.wordpress.org/themes/basics/main-stylesheet-style-css
• wordpress.org/documentation/article/site-health-screen
• developer.wordpress.org/advanced-administration/debug/debug-wordpress
• developer.wordpress.org/cli/commands/cli/info
• cloud.alskyline.com/hosting