WordPress 6.x and 7.0 have dropped the “beta” label for PHP 8 versions, which changes how we talk about WordPress PHP support. This was long overdue. For years I have watched clients and web hosts put off upgrades because that “beta” tag read like a warning instead of a progress report.
So the core team retired the label retroactively. The docs change is small, but it tells hosts and plugin authors that the engine underneath is stable. If you have been putting off a refactor or a server upgrade, that excuse is gone and it is time to ship.
The new WordPress PHP support matrix
The documentation is now much more direct about modern versions. These are listed with full, non-beta support:
- WordPress 6.9 and 7.0: Fully support PHP 8.5.
- WordPress 6.8 and later: Fully support PHP 8.4.
- WordPress 6.4 and later: Fully support PHP 8.3.
The minimum recommended version is still 8.3. The floor has moved with WordPress 7.0, though: PHP 7.2 and 7.3 are no longer supported at all. I covered why WordPress 7.0 dropped older PHP versions in my previous breakdown.
Why the “beta” label had to go
In 14 years of dev work I have seen how much labels shape behavior. The “beta” designation was meant to admit that WordPress doesn’t run in a vacuum; it depends on a pile of plugins and themes. Instead of encouraging people to test, it became a bottleneck. Web hosts pointed at the “beta” label as a reason to keep users on old stacks like PHP 7.4.
Running PHP 7.4 in 2026 means waiting for the next security hole to find you. It is still the “minimum supported” version for WordPress 7.0, but it has been End-of-Life (EOL) for years. If you are still on it, you are not playing it “safe”, you are a target. PHP 8.4 and 8.5 run faster and handle memory better, which you will notice on high-traffic WooCommerce stores.
Checking your environment compatibility
Before you jump to 8.5, check your environment. I usually reach for WP-CLI to catch obvious fatal errors in custom code. This is a quick way to see your current version and whether your site is ready for current WordPress PHP support standards.
# Check current PHP version
php -v
# Check if WordPress recognizes the environment via WP-CLI
wp core check-update
# Run a lint check on your custom plugin directory
find wp-content/plugins/my-custom-plugin -name "*.php" -exec php -l {} \;If you see “No syntax errors detected,” you are halfway there. Linting won’t catch logic changes, though, or deprecated functions that only fire when a specific hook runs.
If this WordPress PHP support work is eating your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
What to do in 2026
Retiring the beta label means the 8.x series is the standard now. Don’t let legacy code drag your performance down. Move your staging environment to PHP 8.4 or 8.5, watch the error logs for transient or race condition problems, and then get production onto a secure, supported version. The official WordPress Requirements and PHP Supported Versions pages have the latest numbers.
