Your PHP version: why it matters for speed and security

WordPress is written in PHP. Every page that doesn't come from a cache is built by the PHP on your server, so its version decides how fast the site loads, whether it gets security fixes, and which plugins you can install.

Every version has an expiry date

A PHP version gets two years of active support, with bug and security fixes, then two more years of security fixes only. After that, nobody fixes it. In short, as of mid-November 2026:

• PHP 7.4 and 8.0 have received nothing since 2022 and 2023 respectively.
• PHP 8.1 went out of support on 31 December 2025.
• PHP 8.2 still gets security fixes until 31 December 2026, a few more weeks.
• PHP 8.3 gets security fixes only, until 31 December 2027.
• PHP 8.4 has active support until the end of 2026 and security fixes until 31 December 2028.
• PHP 8.5 has active support until the end of 2027.

Some Linux distributions patch old versions themselves, so a host's PHP 7.4 isn't necessarily as vulnerable as PHP 7.4 downloaded in 2022. Still, current plugins and WordPress releases are tested on the newer versions, and plugins are starting to require PHP 8 outright.

What you gain in speed

The big jump was from PHP 5.6 to PHP 7, when many WordPress sites loaded almost twice as fast. Between 8.x versions, the gains for WordPress are smaller, a few percent from one version to the next, and they add up if you skip two or three.

OPcache matters just as much: it keeps PHP code compiled in memory so it isn't read and compiled again on every request. At AYT, OPcache is on for every account, with JIT on PHP 8. JIT helps mostly with heavy computation; in WordPress, where much of the time goes to the database, its effect is modest.

What can break when you switch

WordPress core adapts quickly to new PHP versions. The trouble almost always comes from plugins and themes that haven't been updated in years. A few examples:

• PHP 8.0 removed old functions such as create_function() and each(). A plugin still using them stops the site with a fatal error.
• PHP 8.0 is stricter about operations on the wrong types, and some old warnings became errors.
• PHP 8.2 deprecates dynamic properties. That only produces warnings in the log, but you'll see them on the page if WP_DEBUG is on.

To find out which version you run, open Tools → Site Health → Info → Server in wp-admin. In the AYT panel you see and change it in each site's PHP settings.

How to move to a new version

1. Update WordPress, the theme and the plugins. Most compatibility problems have already been fixed by their authors.
2. Look for abandoned plugins. Each plugin's page on WordPress.org shows when it was last updated. A plugin untouched for two years is worth replacing anyway.
3. Make a backup, or check the date of last night's.
4. Switch the version, then go through the important pages: the home page, a post, the contact form, the cart and checkout on a shop, wp-admin.
5. Open the error log and look at the last few minutes. Warnings (Deprecated, Warning) don't stop the site, but they tell you which plugin needs updating soon.
6. If something breaks, switch back to the previous version from the same place and write to the plugin's author.

The settings that go with the version

Along with the version, check a few PHP settings. memory_limit matters for page builders and imports. upload_max_filesize decides how large the files you upload from wp-admin can be. max_input_vars matters for menus with many items: if saving a menu drops the last lines, it's usually too low. At AYT you change all of them, along with PHP extensions, from the panel, for each site.

You'll find the other per-site settings in the AYT panel on the features page.