Update Your PHP Version in WordPress Without Breaking It (October 2026)

WordPress should run PHP 8.3 or 8.4 in October 2026, on a build released on or after 21 October (8.3.36 or 8.4.27 and later), because WordPress recommends 8.3 or newer and PHP still fixes both versions. WordPress's requirements page recommends "PHP version 8.3 or greater" and says it "also works with PHP 7.4+", while warning that those older versions have reached their official end of life. WordPress 7.0 and 7.1 support PHP 7.4 through 8.5, per the core compatibility table.

This month it matters more than usual. PHP's advisory for PHP2Shell lists fixed releases for 8.2, 8.3, 8.4 and 8.5 only. My plain-English guide to the PHP2Shell vulnerability covers the news and the first 24 hours; this post is the careful fix for WordPress.

Here's how WordPress sites are spread across PHP versions, from wordpress.org's live statistics on 23 October 2026 (sites that check in with wordpress.org for updates):

Add up the bottom four rows: about 36% of WordPress sites run a PHP version the PHP project no longer patches. Another 24% sit on 8.2, which has 69 days left. Below 8.3, you're in the majority. It's still the wrong place to be.

The Site Health warning "Your site is running on an outdated version of PHP" means wordpress.org has told your site that its PHP version no longer gets security updates, and WordPress shows it today for PHP 8.0 and older. WordPress asks wordpress.org about your version once a week and shows one of three messages under Tools, Site Health:

• 8.3 and newer: "Your site is running a recommended version of PHP".
• 8.1 and 8.2: "Your site is running on an older version of PHP", which "should be updated". It's listed as a recommended improvement.
• 8.0 and older: "Your site is running on an outdated version of PHP", which "does not receive security updates", listed as a critical issue. Below 8.0 it adds that it "soon will not be supported by WordPress", and the dashboard shows a "PHP Update Required" box.

Two things the warning won't tell you. It checks the version branch, not the patch: I ran WordPress's version check on 23 October, and an unpatched 8.3.20 comes back as a recommended version, same as the fixed 8.3.36. Green Site Health does not mean PHP2Shell is fixed.

And it still marks PHP 8.1 as receiving security updates, although PHP's end-of-life list shows 8.1 support ended on 31 December 2025. WordPress's own source code admits the label is loose: a comment says the "is_secure" flag "doesn't actually imply this is a secure version of PHP".

For the exact patch number, see my guide on how to check your website's PHP version. One wrinkle: some hosts patch without changing the number. Ubuntu 22.04's fixed PHP still reports itself as 8.1.2, so if the number looks old, ask your host.

Updating PHP in WordPress safely takes nine steps in this order: back up, make a staging copy, update everything, check compatibility, switch PHP on staging, test, switch the live site, watch the error log, and keep a rollback ready. The switch is step seven. Jumping straight to it is how sites break.

1. Back up files and database, and keep a copy off the server. The host's nightly backup only counts if you can restore it yourself.
2. Make a staging copy that can run its own PHP version. SiteGround's Staging tool and several other hosts make one in a click. In cPanel's MultiPHP Manager the version is set per domain, so a copy on staging.yourcompany.sg can run 8.4 while the live site stays put; a copy in a subfolder usually can't. The free WP STAGING plugin makes the copy, though pushing changes back to live is paid.
3. Update WordPress, every plugin and the theme while still on the old PHP. Most PHP 8 fixes arrive as ordinary updates. Renew lapsed premium licences first (page builders, sliders, booking plugins), or those updates never arrive.
4. Run a compatibility check, and don't trust it fully. The next section explains why.
5. Switch staging to the version you want to end up on. Go straight to 8.3 or 8.4. Stepping through 8.0, 8.1 and 8.2 on the live site is three rounds of risk for nothing.
6. Test staging with the checklist below, with error logging on.
7. Switch the live site in your hosting panel. The click-paths for cPanel, Plesk, hPanel, Site Tools and the hosts Singapore businesses use are in my guide to changing the PHP version in cPanel and other hosts. Pick a weekday morning when you can watch the site.
8. Watch the error log for 48 hours. A fatal error shows in minutes. A broken scheduled job shows the next time it runs.
9. Keep the old setting one click away, and decide now which version you'd go back to.

PHP compatibility checkers catch only part of the problem, because they read code without running it, and the best-known WordPress one, WP Engine's PHP Compatibility Checker, is no longer maintained and only checks up to PHP 8.0. Its plugin page now opens with "PHP Compatibility Checker is no longer actively maintained", it was last tested with WordPress 6.4, and its own description says it "cannot detect runtime compatibility issues". It still shows 200,000+ active installs.

Developers use PHPCompatibilityWP, a ruleset for the PHP_CodeSniffer tool, run from the command line over the plugin and theme folders. It's more current, but it still reads rather than runs code, and its maintainers say coverage "is not yet 100%". What static checks typically miss:

• Code that only runs in one place: a checkout step, a shortcode on one page, a monthly report.
• Encrypted premium plugins (ionCube) that need a loader installed for the new PHP version.
• Settings that don't carry over. Many hosts keep extensions and php.ini values per PHP version, so a memory limit raised on 7.4 in 2021 can be back at the default on 8.4.
• Behaviour that changes without an error. In PHP 8.0, 0 == "foo" went from true to false, per PHP's 8.0 migration notes, so old form validation can quietly accept or reject the wrong thing.

Use a checker for a list of suspects. Let staging decide.

After changing the PHP version, test every page type and every action that runs code (forms, logins, the editor, uploads, search, checkout and scheduled jobs) while WordPress writes errors to a log file. In wp-config.php, set WP_DEBUG and WP_DEBUG_LOG to true and WP_DEBUG_DISPLAY to false, and errors go to wp-content/debug.log instead of onto the page. WordPress's debugging guide covers each setting and says not to leave debugging on for a live site. Then click through:

• The home page, your three busiest pages, a blog post and the 404 page. Look for a white screen or warning text across the top.
• Every form. Send a real test enquiry and check the email arrives; mail plugins break quietly.
• Logging in, editing a page in your editor or page builder, saving and previewing.
• Uploading an image and checking the resized versions appear.
• Search, menus, sliders, galleries, maps and the WhatsApp button.
• Anything behind a login: members' areas, bookings, customer accounts.
• Scheduled jobs. Schedule a post five minutes ahead and see if it publishes, then check Site Health for a failed or late scheduled event. Backups and abandoned-cart emails run on the same scheduler.
• Your SEO plugin's sitemap, and your cache (clear it after the switch).

Then read debug.log. A "Deprecated" line is a warning about the next version; "Creation of dynamic property" is the one PHP 8.2 made common. A "Fatal error" or "Uncaught Error" line is a page broken now, and its file path names the plugin to blame.

You roll back a PHP update by switching the version back in the same hosting panel, which takes effect within seconds; restore the backup only if a plugin changed the database while the new version was running. Clear every cache afterwards, Cloudflare included, or visitors keep seeing the broken page.

The catch this month is where you roll back to. Going from 8.4 back to 8.1 lands on a version with no official PHP2Shell fix, and CISA's alert of 21 October says systems that can't be patched, or run 8.1 or older, should come offline until they are. So roll back one supported step (8.4 to 8.3, or 8.3 to 8.2) and fix the failing plugin from there.

WordPress has a safety net too. Since version 5.2, when a plugin causes a fatal error, WordPress shows visitors a "technical difficulties" page and emails the admin address a recovery-mode link, which lets you log in with the broken plugin paused (the core team's write-up). Check that the admin email reaches someone who still works for you. On plenty of Singapore SME sites it still goes to the developer who built the site in 2019.

If a plugin only works on PHP 7.4, update it, replace it or have its code fixed, and move PHP anyway, because 7.4 got no official PHP2Shell release and WordPress plugins are dropping it. It's a common trap: someone tried PHP 8 in 2022, the site broke, they switched back, and it has sat on 7.4 since. About 16% of WordPress sites still do, nearly four years after PHP stopped supporting it.

The usual causes are abandoned plugins and old page builders or premium themes whose licence lapsed. PHP 8.0 removed functions such as create_function() and each() outright, so code that calls them stops dead. Signs a plugin is abandoned:

• Its wordpress.org page says it has been closed, or "hasn't been tested with the latest 3 major releases of WordPress".
• No update in two years or more.
• The company that sold it has gone, or the licence key belongs to a developer who has.

Don't read "Requires PHP: 7.0" as a promise that a plugin works on 8.4. That field is a minimum, and WordPress has no maximum field, so nothing warns you before an old plugin meets a new PHP.

Options, cheapest first: update it, swap it for a maintained plugin, pay a developer to fix the lines that fail, or drop the feature. If what's pinning you is the page builder the whole site is made of, a rebuild is often the fix. Some hosts can keep an old version patched for a while; which vendors did that for PHP2Shell, and every version's dates, are in PHP end of life: which versions are still supported. That buys months, not years.

Updating PHP on a WooCommerce store needs one extra round of testing, a test order taken from cart to confirmation email, because checkout and payment gateway plugins are the code most likely to fail in front of a customer. WooCommerce's server recommendations ask for PHP 8.3 or greater and say it's tested up to 8.4. For a shop, I'd move to 8.3 or 8.4 and leave 8.5 until WooCommerce lists it.

WooCommerce has set its own date, too: WooCommerce 11.6 will require PHP 8.1 or newer, planned for February 2027. Stores on 7.4 or 8.0 can update as far as 11.5, which gets critical fixes only, for a limited window. WooCommerce counted about 7% of tracked stores on 7.4 and 2% on 8.0.

On staging, put the payment gateway in test mode and:

1. Add two products, apply a coupon and check delivery options for a Singapore address.
2. Pay with every method you offer: card, PayNow, PayPal. Each gateway is its own plugin with its own PHP.
3. Check the order shows as Processing, stock drops, and both customer and admin emails arrive.
4. Check what runs after payment: invoice PDFs, accounting or delivery integrations, the gateway's callbacks.
5. Refund the test order.

Then switch live in your quietest hour. With 11.11 and Black Friday coming, I'd do it in the next two weeks, not mid-sale.

You can update PHP in WordPress yourself if your plugins are current, your host offers staging and you have a few hours to test; hand it over if the site takes payments, runs on a page builder nobody has updated in years, or nobody knows the hosting login. That second group describes a lot of Singapore SME sites, where whoever built the site moved on long ago.

This is work I do for clients, and it starts with a free PHP check:

• The free check. Send me your web address and I'll check which PHP version it runs, what it's built on and how old its theme and plugins are, then tell you what I find. If your host has already patched it for free, I'll say so, and you don't need me.
• The fix. If it needs the update, you get a fixed price in writing before I start, covering the PHP update and anything it breaks, from SGD 850. It's part of my website maintenance service.
• Upkeep. The content retainer at SGD 550 a month covers core, plugin, backup and security work plus 5 hours of changes, month to month.

If the check shows the site can't get past 8.1 without rebuilding half of it, I'll quote a rebuild next to the fix so you can compare. A static site built with Astro and served from a CDN has no PHP running on the server, so a flaw like PHP2Shell has nothing to reach. That's how I rebuilt MET Interior's 176-page site after WordPress and its page builder became the bottleneck, and how terris.sg runs. A Starter rebuild is from SGD 2,535, the One Week Website is SGD 3,545, and Growth, from SGD 7,585, includes a CMS you edit yourself. My guide to moving off WordPress to a static site has the full route.

Static still has things to protect: the domain registrar and DNS, the hosting account, form handlers, third-party scripts. It just has no PHP runtime, no database and no public login page. For a big WooCommerce catalogue or a membership site, a well-kept WordPress on a patched PHP is usually the better answer, and patching is what I'd recommend.

No, you can't update PHP from the WordPress dashboard, because PHP is the server software WordPress runs on; you change it in your hosting control panel or ask your host to change it. The "Learn more about updating PHP" button in the dashboard warning opens a help page on wordpress.org, or your host's own instructions if the host has set them up. On a VPS with no control panel, it's a command-line job for whoever runs the server.

A WordPress PHP update takes seconds to switch and anywhere from a couple of hours to a few days to do safely, depending on how many plugins the site runs and whether it takes payments. A brochure site with current plugins and one-click staging is an afternoon's work. A WooCommerce store with lapsed premium plugins takes longer, because every failed test sends you back to fix a plugin before the next try.

A security plugin such as Wordfence or Kadence Security (formerly Solid Security) can't be relied on to protect a WordPress site from PHP2Shell, because the plugin is itself PHP code and PHP says the worst form of the attack fires before any application code runs. PHP's advisory describes a mod_php exploit where an unauthenticated request "can trigger the attack before any application code runs". A firewall at your host or CDN may block known attack patterns, which CISA says "may provide some protection" until you patch. Updating PHP is the fix.

PHP 7.4 can be patched against PHP2Shell if your host uses a vendor that backports fixes, but treat that as time to plan the move rather than a reason to stay. CloudLinux says fixed alt-php builds from 5.2 to 8.5 reached its stable channel on 22 October, and Ubuntu fixed PHP 7.4 on Ubuntu 20.04 for Ubuntu Pro subscribers. Get your host's answer in writing. Then move: WooCommerce needs PHP 8.1 from February 2027, and WordPress already labels anything below 8.0 as soon to be unsupported.