Still on PHP 7.4 on WordPress? How to Upgrade Safely

Key takeaways

• Aim for PHP 8.3 or newer. On 22 October 2026 we checked the WordPress.org requirements page, which recommends "PHP version 8.3 or greater". It lists 7.4 as past its official end of life.
• Neither 7.4 nor 8.0 receives an official patch for the October flaws. Patched builds are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Read the full story in our PHP vulnerability guide.
• The risk of the jump is old code, not WordPress. PHP 8 is stricter. Old themes and plugins that sat quietly on 7.4 can show warnings or a white screen on 8.x.
• Test on a copy first. Make a backup, clone the site to a staging copy, switch PHP there, and click through the pages that make you money.
• Update everything before you change PHP. Newer plugin and theme versions are usually the whole fix.
• If one plugin cannot move, replace it. Staying on 7.4 for one plugin keeps the entire site on a branch that gets no fixes.

Why the version you run matters now

PHP is the software on your host's server that runs WordPress. Each branch is supported for a fixed time. Every date is listed in our PHP end of life dates guide, so the table is not repeated here. The short version, from php.net's pages read on 22 October 2026: 7.4 and 8.0 are out of support, 8.1 is out of support, and 8.2 only gets security fixes until 31 December 2026.

The advisory php.net published on 21 October 2026 lists two critical flaws: CVE-2026-109618 and CVE-2026-109619. Fixed versions exist for 8.2 to 8.5. For 8.1 and older, the project says it no longer provides updates. No WordPress update is required, says WordPress.org, since the patch lives on the server.

So if your site shows 7.4 or 8.0 in Site Health, the plan is simple to say and harder to do: move to a supported branch, and make sure the site still works afterwards. Not sure which version you run? Our walkthrough on checking and updating your PHP version tells you where to look.

What actually changes between PHP 7.4 and 8.x

The PHP manual's migration pages, read on 22 October 2026, describe three kinds of change.

Things that were removed

Some old functions are gone in PHP 8.0, such as create_function() and each(), per the manual. Code that calls them stops with a fatal error.

Things that were quiet and are now loud

In PHP 7.4, many mistakes in code only produced a notice or a warning that nobody saw. PHP 8.0 turned several of them into real errors. The manual says that using the wrong kind of value in arithmetic, calling count() on something that is not a list, or writing to a property of a value that is empty now throws an error. A site that "worked" because nobody looked at the log can stop working.

Comparisons also changed. The manual shows that 0 == "foo" is now false, where it used to be true, so old code can behave differently.

Things that still work but are marked for removal

A deprecation is a warning that something will be removed later. The code still runs. The manual lists several that old WordPress code meets:

Deprecation notices do not break a page by themselves. A good developer reads them as a to-do list.

The upgrade ladder we would follow

Should you step through 8.0 and 8.1 or go straight to 8.3? Here is our answer, using only what WordPress.org and php.net publish.

WordPress.org recommends 8.3 or greater. php.net lists 8.0 and 8.1 as past their end. That makes 8.0 and 8.1 poor places to stop on a live site. The compatibility table kept by WordPress, which we read on 22 October 2026, shows PHP 8.0 to 8.4 as supported on 6.9, 7.0 and 7.1, the three newest WordPress releases listed. WordPress itself is not what blocks you.

Stepping through 8.1 can help as a temporary test on staging if 8.3 shows a long list of errors. Do not leave a live site there, because 8.1 gets no fix for the October flaws. Security support for 8.3 runs to 31 December 2027 per php.net, and 8.4 and 8.5 are supported too where your host provides them.

Hosts differ in what they offer. Our guide to asking your host about the PHP fix lists what to ask, and the difference between plans is covered in managed against shared hosting.

Old themes and plugins that block the move

Most failed upgrades come from one plugin or one theme. Here is how to find which one without guessing.

1. Switch PHP on staging and read the error. If you get a blank white page or an error naming a file path, that points at the culprit. The folder name under wp-content/plugins or wp-content/themes is the name of the plugin or theme.
2. Turn on debug logging. WordPress can write errors to a log file instead of showing them on the page. The log lists every file that complains, with a line number.
3. Look at the plugin's page on WordPress.org. If the last update is years old, or the page says it has not been tested with recent WordPress versions, treat it as a risk. We read no official rule that says a plugin must be tested to run on a given PHP, so judge by the update date and by what the log says.
4. Switch plugins off one at a time on staging. If the site comes back when one is off, you have found it.
5. Check the theme. A theme that has not been updated for years is the usual blocker. A child theme with old custom code is the next one to check.

Some plugins pass the first look and fail on one task, such as sending a form or taking a payment, so test the full path. For shops, our guide to WooCommerce and the PHP flaw covers checkout tests.

When something cannot be updated

Sometimes the plugin is abandoned, the theme was built by someone who left, or the add-on is a paid tool with no new version. You have four options, in this order of preference.

The option we do not recommend is to stay on 7.4 or 8.0 "because the plugin needs it". For those branches the php.net advisory offers no official patch, and the WordPress.org requirements page warns that end of life versions "may expose your site to security vulnerabilities". A firewall can reduce some risk but does not replace the update, as our guide to firewalls and PHP updates explains.

What is still unclear, and when this advice does not apply

• Your site is unseen by us. The ladder is a method, not a promise that nothing will break.
• Your host may not offer 8.3. Ask for the newest supported version it does offer, and whether it is time to change host.
• Some hosts patch old PHP themselves. According to php.net, certain Linux distributions and long term support vendors could ship backported patches for older branches. We could not confirm what any single host does, so ask and ask for it in writing.
• Sites on Webflow, Shopify, Wix, Squarespace or Framer never expose PHP to you, so none of this guide is relevant to them. Our note on Webflow and PHP covers that case.
• If you suspect a hack, an upgrade does not clean it. See how to check a hacked WordPress site.

How we help at Amariq

Jumping from a very old PHP to a current one is where sites most often break, because several years of changes arrive in one step. Our team carried out upgrades like this on WordPress sites in the day after the advisory, with a backup first and a test of the pages that matter. If your theme or a plugin cannot move, we will say so plainly and give you the options. Our WordPress PHP update gig on Fiverr is priced around the size of your site, while the WordPress development page covers the wider work. Ahead of ordering, you can read what our Fiverr and Upwork clients wrote and watch a video or two on our YouTube channel.

Frequently asked questions

Can I go straight from PHP 7.4 to 8.3?

Yes, on a staging copy first. The advice from WordPress.org is 8.3 or greater, and the newest WordPress versions are listed as working on 8.0 through 8.4. The real question is whether your theme and plugins cope, and a test on staging answers it.

Will upgrading PHP break my WordPress site?

It can, if a theme or plugin uses code that PHP 8 removed or treats more strictly. Updating everything first, testing on a copy and reading the error log lowers that risk. A backup lets you go back if a page you did not test fails.

Is PHP 8.0 or 8.1 good enough?

No for a live site. php.net lists both as past their end of support, and the October 2026 fixes were published only for 8.2 and newer. They are fine as a short test step on staging, not as a destination.

What if my host only offers PHP 7.4?

Ask when a newer version will be available, and get the answer in writing. If there is no plan, a move to a host with current PHP is the safer route. Take a backup and plan the move so that email and DNS records are not affected.

My plugin is no longer updated. What now?

First look for a maintained plugin that does the same job. If nothing fits, a developer can fix the old code or rebuild the one feature. Staying on an unsupported PHP version to keep it running leaves the whole site exposed.

Can I hire someone to do the upgrade for me?

Yes, and for most owners that is the sensible choice, because the work sits on the server and in the code. Ask for a backup first, a staging test, a list of what was changed and a before and after check of your key pages.

Sources, read 22 October 2026: php.net supported versions, the manual pages for 8.0, 8.1 and 8.2, WordPress.org requirements and the PHP compatibility table.