PHP 8.1 is end-of-life: is your WordPress site ready for PHP 8.4?

PHP 8.1's security support ended on December 31, 2025. No more patches. If a vulnerability is discovered in PHP 8.1 tomorrow, it stays unfixed, permanently.

That matters because nearly half of all WordPress sites were still running PHP 8.1 or older at the start of this year. Many hosting providers responded by force-upgrading those sites to PHP 8.3 or 8.4. Some handled the jump gracefully. Others broke.

If your site stopped working after a PHP upgrade, you're not alone, and it's fixable. If you're not sure which version you're running, that's the first thing to check.

TL;DR:

• PHP 8.1 received its last security patch on December 31, 2025; it's now permanently unsupported
• About 47.5% of WordPress sites were still running PHP 8.1 or older at that point
• The biggest source of breakage: plugins not yet updated for PHP 8.4's stricter type handling
• WooCommerce, Elementor, and WPML all had documented issues, most fixed in recent versions
• The safest approach: update all plugins first, test on a staging environment, then switch PHP version

In this article

• What happened on December 31, 2025
• How to check which PHP version your site runs
• What breaks when you jump from PHP 8.1 to 8.4
• Which plugins had problems
• The safe upgrade path
• Don't settle on PHP 8.2
• Key takeaways

What happened on December 31, 2025

PHP versions follow a predictable lifecycle. Each version gets two years of active development, then two years of security-only patches. After that: nothing. PHP 8.1, released in November 2021, hit that wall on December 31, 2025.

This isn't theoretical risk. Any security vulnerability found in PHP 8.1 from January 1, 2026 onward stays open. There is no patch coming. And PHP 8.1 isn't alone: PHP 8.0 went end-of-life in November 2023, and PHP 7.4 all the way back in November 2022. If you're on any of those, you're running unpatched server software. WordPress 7.0 is even dropping support for PHP 7.2 and 7.3 entirely when it ships in April 2026, so sites on those versions won't just be insecure, they'll be unable to update WordPress.

The hosting industry didn't wait. WP Cloud (Automattic's infrastructure powering WordPress.com and Pressable) automatically upgraded remaining PHP 8.1 sites to 8.4 on the deadline. WP Engine, Kinsta, and SiteGround followed similar policies: email warnings months in advance, then forced migration on or before the cutoff date.

The result: a lot of sites got pushed from 8.1 straight to 8.3 or 8.4, skipping two or three PHP versions at once. That's where things got messy.

How to check which PHP version your site runs

The quickest way is inside WordPress itself:

1. Go to Tools > Site Health in your WordPress dashboard
2. Click the Info tab
3. Expand the Server section
4. Look for PHP version

This works on any WordPress 5.2+ site without additional plugins. The Site Health screen also flags outdated PHP with an explicit recommendation to upgrade.

If you don't have WordPress access, your hosting control panel will show it too: in cPanel it's under "MultiPHP Manager," in Plesk under "PHP Settings," and in managed platforms like Kinsta or SiteGround it's usually right on the site's dashboard.

WordPress.org currently recommends PHP 8.3 or newer.

What breaks when you jump from PHP 8.1 to 8.4

PHP evolves by deprecating features in one version and removing or enforcing them in later versions. When you skip multiple versions at once (say, 8.1 to 8.4), you hit all those changes simultaneously. Here are the ones WordPress site owners encounter most.

Implicitly nullable parameters

This is the single biggest source of PHP 8.4 breakage in the WordPress ecosystem. In PHP 8.1, you could write function foo(string $name = null) and PHP silently accepted it. In PHP 8.4, this triggers a deprecation warning. The code still works, but your error log fills up. And if your site displays errors to visitors? They see ugly PHP warnings instead of your content.

Nearly every major plugin was affected. The fix is simple in code (add a ? before the type: ?string $name = null), but you're dependent on plugin authors shipping the update.

Dynamic properties

Since PHP 8.2, assigning a property that doesn't exist in a class definition triggers a deprecation warning. Older plugins, especially those built before 2022, commonly set arbitrary properties on objects. The warnings are noisy but not fatal. In PHP 9.0 (still years away), these become actual errors.

Removed or deprecated functions

A handful of PHP functions that plugins relied on were deprecated or removed along the way:

• utf8_encode() and utf8_decode(): deprecated in PHP 8.2, removed in 8.4
• FILTER_SANITIZE_STRING: deprecated since PHP 8.1, still generates notices
• The IMAP extension: moved out of core in PHP 8.4, only available separately

If a plugin calls one of these without checking availability, you get a fatal error, not a warning.

Which plugins had problems

The good news: most major plugins have shipped fixes by now. But if you haven't updated in a while, you might still be running the broken versions.

WooCommerce had a genuine fatal error (not just warnings) in its auto-updater module when running on PHP 8.4. The updater passed a string where PHP 8.4 expected an integer, which prevented WooCommerce from updating itself. Fixed in WooCommerce 10.4.2 (December 2025).

Elementor generated dozens of nullable parameter warnings across its frontend, editor, and admin. Fixed in Elementor 3.32, though some third-party Elementor addons may still have issues.

WPML was one of the worst offenders: users reported hundreds of deprecation notices flooding their error logs after upgrading to PHP 8.4.

Wordfence needed a compatibility fix when PHP security patches changed how certain functions throw exceptions. Wordfence 8.1.4 addressed this.

Rank Math had warnings in its analytics and WooCommerce modules, specifically number_format() and strpos() calls with null values.

Contact Form 7 and Gravity Forms fixed their PHP 8.4 issues relatively quickly. Gravity Forms confirmed full compatibility in December 2025.

The pattern is clear: actively maintained plugins fix these issues within weeks. The real risk sits with plugins that haven't been updated in two years or more. If a plugin's last update on wordpress.org predates 2023, treat it as likely incompatible and start looking for a replacement.

The safe upgrade path

Don't flip the PHP version switch on your live site. Here's the approach that avoids downtime:

1. Update everything first. Update all plugins, your theme, and WordPress core to the latest versions. Many PHP 8.4 issues have already been patched, and updating alone might resolve everything.

2. Test on staging. Clone your site to a staging environment and switch PHP there first. Walk through your critical pages: homepage, contact form, checkout (if you run WooCommerce), and any pages with complex plugin functionality.

3. Enable debug logging. Add this to wp-config.php on your staging site:

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

Then check wp-content/debug.log after browsing around. You'll see deprecation warnings and errors that might not be visible on the frontend but could cause problems down the line.

4. Check for abandoned plugins. Any plugin not updated in two years is a liability, regardless of PHP version. Replace it now rather than fighting compatibility issues later.

5. Switch production. Once staging looks clean, switch PHP on your live site. Keep an eye on the error log for the first few days.

If something breaks after switching, most hosts let you revert to the previous PHP version immediately. The article on recovering from a WordPress update gone wrong covers the general recovery approach.

A note about the PHP Compatibility Checker plugin by WP Engine: it's abandoned. Last updated in 2023, it only checks up to PHP 8.0, and recent reviews call it broken. Don't rely on it. The staging + debug log approach catches more real-world issues anyway.

Don't settle on PHP 8.2

If your host upgraded you to PHP 8.2 instead of 8.4, know that you're on borrowed time. PHP 8.2 enters end-of-life on December 31, 2026, less than nine months from now. You'll be in this exact situation again before the year is out.

PHP 8.4 is the better target. It's actively supported until December 2028, and WordPress has beta support for it, which in practice means WordPress core runs fine; the label simply reflects that ecosystem-wide plugin testing is still catching up. WordPress.org officially recommends PHP 8.3 or newer, and most actively maintained plugins support 8.4 already.

PHP 8.4 also brings real improvements: property hooks, new array functions, and better HTML parsing. Your site won't benefit from those directly, but the plugins you depend on will start using them, and they perform better on 8.4 than on older versions.

Key takeaways

• PHP 8.1 has been end-of-life since December 31, 2025. Running it means running permanently unpatched server software.
• Check your version via Tools > Site Health > Info > Server in WordPress.
• Most breakage comes from plugins, not WordPress core. Updating plugins to their current versions fixes the majority of PHP 8.4 issues.
• Always test PHP upgrades on staging first. Enable WP_DEBUG_LOG and check the log after browsing your key pages.
• Target PHP 8.4 directly. PHP 8.2 goes end-of-life in December 2026, so don't upgrade twice when you can do it once.