How to Update PHP on WordPress and WooCommerce Without Breaking Your Site

On October 21, the PHP project shipped security releases for every supported branch: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They fix two vulnerabilities rated 9.2 on CVSS v4, both described as remote code execution. The php.net announcement is blunt about it: “There are no complete mitigations, updating is the only safe choice.”

The same day, the WooCommerce developer blog told store owners to update PHP right away. This isn’t a WordPress or WooCommerce bug. It affects any server running PHP.

Most of the time a PHP update is a dropdown in your hosting panel. The reason people put it off is fear: the last time someone flipped that switch, a plugin threw a fatal error and checkout went white.

Here’s the process I use on client sites so that doesn’t happen.

First, know which kind of update you’re doing

There are two very different jobs hiding behind “update PHP”.

A patch update moves you within the same branch, for example 8.3.30 to 8.3.36. These are bug and security fixes. They rarely break anything. On managed hosting they usually happen for you. On a VPS you run them through your package manager.

A branch upgrade moves you from one minor version to another, for example 8.1 to 8.3. This is where old plugins break, because PHP removes deprecated features between branches.

The October fix needs a patch update if you’re already on 8.2 or newer. If you’re on 8.1 or older, there is no patch coming. Per the supported versions page, 8.0 and 8.1 are end of life, and 8.2 stops getting security fixes on December 31, 2026. So for a lot of older stores, the security fix and the branch upgrade are the same job.

Step 1: Find out what you’re running

In WordPress, go to Tools > Site Health > Info > Server. You’ll see the PHP version and SAPI.

If you have SSH and WP-CLI:

wp --info
php -v

One catch: the CLI PHP and the web PHP can be different binaries. Site Health shows what your visitors actually hit, so trust that one.

Write down the exact version. If it’s below 8.2, plan a branch upgrade. WordPress itself recommends PHP 8.3 or greater, and WooCommerce recommends 8.3 or newer too.

Step 2: Check what your host does for you

Before touching anything, check your host’s status page or support docs. Some managed hosts patch PHP within a branch automatically. Per the WooCommerce post, sites on WordPress.com, WordPress VIP, Pressable and WP Cloud were already protected.

If your host manages patch updates, your job is mainly the branch upgrade. If you run your own server, you own both.

Step 3: Make a staging copy

Never test a branch upgrade on the live store. Most hosts offer one-click staging. If yours doesn’t, clone the site to a subdomain with your backup plugin.

Two things to do on the staging copy before testing:

• Turn off outgoing email, or route it to a catch-all. You don’t want staging sending order emails to real customers.
• Disable payment gateway live mode and use test keys.

Also take a fresh full backup of production (files and database) and confirm you can restore it. A backup you’ve never restored is a hope, not a backup.

Step 4: Scan your plugins and theme for compatibility

This is the step most guides skip, and it’s the one that saves you.

For code you control (a custom theme, custom plugins), run PHPCompatibilityWP with PHP_CodeSniffer. It flags functions and syntax that were removed or changed in the PHP version you’re targeting:

composer require --dev phpcompatibility/phpcompatibility-wp:"*"
vendor/bin/phpcs -p wp-content/themes/your-theme \
  --standard=PHPCompatibilityWP \
  --runtime-set testVersion 8.3-

Run it against each custom plugin folder too. Static scans miss some runtime issues, but they catch the obvious breakers in seconds.

For third-party plugins, check each one’s “Tested up to” and changelog on WordPress.org or the vendor site. Anything that hasn’t been updated in two years is a red flag, whatever PHP version you’re on.

Step 5: Switch PHP on staging and turn on logging

Change the PHP version for the staging site in your hosting panel. Then add this to wp-config.php on staging:

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

Errors now go to wp-content/debug.log instead of the screen.

Step 6: Test the paths that make money

Clicking around the homepage isn’t testing. On a WooCommerce store I walk through:

• Product page, including variable products and any custom options
• Add to cart, cart updates, coupon codes
• Checkout with a test payment, start to finish
• The order confirmation email and the admin new-order email
• My Account: login, order history, subscription changes if you sell them
• Admin: edit a product, process a refund, export orders
• Scheduled tasks: go to Tools > Scheduled Actions and check nothing is piling up as failed

Then read debug.log. Fatal errors are obvious. Deprecation notices aren’t urgent, but each one is a breakage waiting for the next branch upgrade, so note which plugin they come from.

Step 7: Switch production, then watch it

If staging is clean, switch production during your quietest hour. Then:

1. Place one real low-value order, or a test order with a test gateway if your setup allows it.
2. Watch the PHP error log for the first hour.
3. Check that cron and scheduled actions keep running.

If you manage many sites, stagger them. Do your simplest sites first and your most customized store last.

Step 8: Know your rollback before you need it

On most hosts, rolling back PHP is the same dropdown in reverse. Know where it is before you start. If a fatal error locks you out of wp-admin, switching PHP back in the hosting panel is usually faster than debugging live.

If you’re on a version below 8.2, rolling back to it is only a short-term fix. Find the plugin that broke, replace or patch it, and try again within days, not months.

How often should you do this?

Patch updates: as soon as they’re released, especially security ones like this month’s. Branch upgrades: plan one a year. PHP ships a new branch every November or December, and each one gets two years of active support and two of security fixes. If you stay one branch behind the newest, you’ll always have runway.

On agency fleets, the hard part isn’t the update. It’s knowing which of your 40 client sites are still on PHP 8.1. That’s one reason I built Plugsent, so I can see versions and pending updates across sites in one place.

FAQ

Will updating PHP break my WordPress site?

A patch update within the same branch almost never does. A branch upgrade can, usually because an old plugin or theme uses removed functions. Testing on staging and scanning custom code first catches most of it.

What PHP version should WordPress use in 2026?

WordPress recommends PHP 8.3 or greater. PHP 8.3, 8.4 and 8.5 all get security fixes, and 8.2 stops getting them at the end of 2026.

How do I check my PHP version in WordPress?

Go to Tools > Site Health > Info > Server. With SSH access, run php -v or wp --info, but trust Site Health for the version your visitors hit.

Do I need to update WordPress or WooCommerce for the October 2026 PHP security fix?

No. The fix is in PHP itself, so you update PHP on the server. WooCommerce has said no WooCommerce or WordPress update is required for it.

Need a hand?

If you’d rather not test a PHP upgrade on a live store yourself, I do this for WooCommerce and WordPress sites: compatibility scans, staging tests, the switch and the cleanup after. Get in touch or see my services.

Agency with a fleet of client sites to move? Betatech works as your white-label WordPress team, NDA included.