Need to upgrade PHP without breaking your site or store?

Why does this happen?

PHP is the language WordPress runs on, and each PHP version gets security fixes for about four years. After that, WordPress, your host and plugin vendors all push you to move. Changing the version is one setting. The work is making sure every plugin, your theme and any custom code still runs on the newer version.

The warning comes from one of three places:

• WordPress itself. Site Health (Tools, Site Health) and a “PHP Update Required” or “PHP Update Recommended” box on the dashboard tell you your version is outdated or no longer receives security updates.
• Your host. Hosts retire old PHP versions on their own schedule. Some switch sites over automatically, and some charge extra to keep an old version running.
• A plugin. When a vendor raises its minimum PHP version, the Plugins screen says the new version does not work with your version of PHP, and WordPress will not install it. You stay on an old release of that plugin, missing its fixes.

What breaks when the version changes, most common first:

• Old code that newer PHP rejects. PHP 8 removed functions that older plugins and themes relied on, such as create_function(), and it turns many old warnings into fatal errors. Counting something that is not a list, which PHP 7 only warned about, now stops the page with a critical error.
• Custom code nobody has looked at in years. Snippets in a child theme’s functions.php or a small custom plugin. No update will fix these; someone has to read them.
• Abandoned plugins. A plugin with no updates for years will not be made compatible by its author. It needs replacing or patching.
• Noisy deprecation notices. Newer PHP versions flag code they plan to remove later, such as “Creation of dynamic property … is deprecated” or “Passing null to parameter #1 ($string) of type string is deprecated”. If your server shows errors on screen, these lines can print on your pages or into the background requests that run the cart and checkout.

Try this first

These checks change nothing on your site, so they are safe on a live store.

1. Find out what you run now. Go to Tools, Site Health, Info and open the Server section to see your PHP version. On WooCommerce, WooCommerce, Status shows it too, under Server environment. Write it down, with any deadline your host has given you.
2. Read the warnings you already have. Open the Status tab of Site Health and note what it says about PHP. Then check Dashboard, Updates and the Plugins screen for any plugin whose update does not work with your version of PHP. Those vendors have already moved on.
3. Check what each plugin says it needs. On the Plugins screen, click “View details” under each plugin and read “Requires PHP Version”. A plugin that has not been updated in years may fail on newer PHP even if it names no limit. Note any plugin or snippet with no details page at all: that is custom code, and only reading it shows whether it is ready.
4. Ask your host three questions, in writing. Does the PHP serving your site include the October 2026 security fix, and was PHP restarted after patching? Is there a staging copy you can switch to the new version first? Can the live site switch back if something breaks?

If your host already switched and the site broke, ask them (or use the PHP setting in your hosting panel) to put the previous version back. That undoes the change without touching your files or orders. If a plugin updated itself in the meantime, it may now need the newer version, so check the site straight after. It is a stopgap, but it gets you trading again while the cause is fixed.

Hand it over when staging shows errors, when the suspect list includes custom code, or when the site is a store. One plugin failing on the new version can quietly stop payments or order emails.

What did the October 2026 PHP flaw change?

In October 2026 PHP shipped emergency security releases for two flaws known as PHP2Shell. They sit in PHP itself, below WordPress, so no WordPress or security plugin update could fix them, as WordPress.org confirmed. The fix had to come from whoever runs your server.

PHP 8.2 to 8.5 got new official releases. PHP 8.1 and older did not, so those sites are covered only if the host applied its own patch, often without changing the version number. An older version does not mean your site was attacked. If you see an administrator nobody created, start with hacked site cleanup.

PHP 8.2 also reaches end of life on 31 December 2026, so PHP 8.3 or newer is the safer target, moved on staging first so the store keeps taking orders.

BoltPress Security, included in every care plan, checks each site’s PHP branch and patch level against PHP’s security releases every day and tells you in plain English when your server falls behind.

What if I am several versions behind?

Then we move in one step to a version that is still supported, not through every version in between, but we test against all the changes along the way. Sites this far behind usually have outdated plugins and an outdated WordPress too. Those come first, because the old plugin versions are the ones that fail on new PHP.

This fix covers the PHP switch and the small repairs it needs. A big jump, say from PHP 7.4, on a site with abandoned plugins or a long list of skipped updates needs those brought current first. That is our WordPress update catch-up, and staging shows which one you need.

If the upgrade has already broken things, start with site broken after an update or the critical error fix. The free WordPress audit flags an end of life PHP version when your server reveals it. Every other fix is on the Fix WordPress page.