WordPress 7.0 lands in April 2026, and it drops support for PHP 7.2 and 7.3. That is a real shift in WordPress PHP support rather than a routine version bump, and after the hours I have lost writing polyfills for ancient hosting environments, I am glad to see it.
The project retires a PHP version once usage falls under 5 percent. PHP 7.2 and 7.3 combined now sit below 4 percent, so the Core team signed off on making PHP 7.4.0 the new minimum. The recommended version stays at 8.3. Raising the floor mostly means core and plugin authors can stop carrying workarounds for two versions that reached end of life years ago.
Why the floor matters for performance
Compatibility is the visible half of this. The real cost is the code you cannot write. PHP 7.4 brought arrow functions and typed properties, both of which make code shorter and quicker to execute, and any codebase that still has to run on 7.2 leaves them on the shelf.
Security is the heavier argument. The PHP group stopped shipping official patches for 7.2 and 7.3 years ago. Pushing the minimum up drags the hosting industry along with it, which is largely the point. If your site is still on one of those versions, it is exposed to exploits that were fixed back in the 8.x branch.
The impact on modern tooling
The Gutenberg plugin is raising its own minimum to 7.4 as well. Modern JavaScript-to-PHP bridges and AI libraries lean on the stricter type handling in newer PHP, and getting AI features into Core needs a runtime that does not choke on current syntax. I went through the wider roadmap in an earlier post on WordPress Core updates and the PHP drop.
How to check your current environment
Site Health will tell you which version you are on, and WP-CLI will tell you faster if you live in a terminal. I prefer the CLI here because the dashboard can hand you a cached value out of a transient and send you chasing a problem that was already fixed.
# Check PHP version via WP-CLI
wp eval 'echo PHP_VERSION;'
# Or get a full environment report
wp core infoIf you ship a custom plugin, put a version check in the bootstrap file now so nobody activates it on an environment that cannot run it:
<?php
/**
* Plugin Name: BBIoon Custom Logic
*/
function bbioon_check_php_version() {
if ( version_compare( PHP_VERSION, '7.4.0', '<' ) ) {
deactivate_plugins( plugin_basename( __FILE__ ) );
wp_die( 'This plugin requires PHP 7.4 or higher.' );
}
}
register_activation_hook( __FILE__, 'bbioon_check_php_version' );What happens if you cannot upgrade
There is a safety net and it is a thin one. Once 7.0 ships, sites on PHP 7.2 or 7.3 stay parked on the WordPress 6.9 branch. Security fixes still get backported as a courtesy as far down as version 4.7, but new features, performance work and block editor changes stop arriving. The site becomes an archive that happens to still be online. The WordPress Core Handbook has the full version matrix.
If a PHP upgrade audit is eating your dev hours, I can take it off your plate. I have been working with WordPress since the 4.x days and have moved hundreds of legacy sites onto modern stacks.
What to do before April
April 2026 sounds far off until you have to book a maintenance window through a change board. Audit your themes and plugins now, look for deprecated functions, and confirm your host offers at least PHP 8.2, which is the steadiest option right now. Leave it until the release and you find out during an update you cannot postpone. I covered the rest of the release in my breakdown of WordPress 7.0 developer features.
