WordPress 7.0 raised the minimum PHP version to 7.4. If your site is below that, the update either refused to run or something on your site broke without an obvious cause. If you are on 7.4 or above, this does not affect you today, but one part of it still might: 7.4 itself has reached end of life, and WordPress.org is explicit that it "may expose your site to security vulnerabilities."
Version and verification. Written against WordPress 7.0.2, released 2026-07-17, current stable. WordPress 7.0 shipped 2026-05-20 and raised the PHP floor. Last verified 2026-08-06 against wordpress.org.
The short version: are you affected right now
Two separate questions, and they have different urgency:
- Are you below 7.4? If yes, this is why an update failed or a feature broke, and it needs your host's attention before anything else on this site's update cluster.
- Are you at exactly 7.4? The site works, but you are on a version WordPress.org itself says has reached end of life. That is not an emergency, but it is a conversation worth having with your host on its own schedule.
If you are already on 8.0 or higher, you can stop reading the urgent part of this article and skip to the section on where WordPress.org recommends you actually be.
How to check your PHP version in two places
In WordPress itself: go to Tools > Site Health > Info, expand the Server section, and scroll to PHP version. This is the version WordPress is actually running on, which is the number that matters, not a number your host's marketing page quotes.
While you are on the Site Health screen, check the Status tab too. If your PHP version is below what WordPress.org currently recommends, Site Health raises this as a flagged issue, typed as Security, specifically because outdated PHP is a security exposure, not only a compatibility one.
At your host, without logging into WordPress at all: most hosting control panels expose a PHP version selector, commonly labeled something like "PHP Selector" or "MultiPHP Manager" on cPanel-style panels. The exact name and location vary by host, so this is described generically rather than as a specific claim about any one host's panel.
What "PHP 7.4 is the minimum" actually means for a site below it
WordPress.org states it plainly: PHP 7.4 or greater is required. Support for PHP 7.2 and 7.3 ended with the 7.0 release. If your site is below 7.4, one of two things happened when 7.0 tried to update:
- The update refused to run at all, and your site is still on the version before 7.0.
- The update ran anyway (some hosting environments do not enforce the check strictly) and something broke, because code written for 7.0 assumes language features that do not exist on older PHP.
Either way, the fix is the same: get your PHP version raised before you retry anything else in this cluster. A pre-update checklist, a plugin-compatibility check, or a rollback are all the wrong next step if the underlying PHP version is still below the floor, since they solve a different problem than the one you actually have.
7.4 works, but it is not where WordPress.org recommends you stop
This is the distinction most guides skip. WordPress.org's own requirements page recommends PHP 8.3 or greater, and states the reasoning directly: PHP 7.4 "still functions but has reached official End Of Life," which means it no longer receives security fixes from the PHP project itself, independent of anything WordPress does.
The database side has the same shape: WordPress.org recommends MariaDB 10.11+ or MySQL 8.0+, though it will still operate on older, unsupported versions.
So there are genuinely two different findings here, and they call for different levels of urgency:
- Below 7.4: this is why things are breaking. Fix it before anything else.
- At 7.4 exactly: the site runs, but you are one step below where WordPress.org recommends you actually be, for reasons that are about ongoing security support rather than this specific update.
Before you touch anything: the backup you have not tested is an assumption
A PHP version change happens at the hosting level, outside WordPress entirely, and it is exactly as capable of breaking a site as a WordPress update is. The failure looks the same from where you sit (a broken admin, a blank page, a critical error), and the fix is completely different, which is the reason this article exists as its own row rather than folding into the general update guide.
Do not schedule a PHP change without confirming, by looking rather than by remembering, that you have a backup you could actually restore from. If you have never restored one, find that out before you need to, not during an outage.
Coordinating the change with your host, in the right order
- Confirm your current version using Tools > Site Health > Info, as above.
- Confirm your backup is real, per the previous section.
- Ask your host to move you to the target version, or use the host's own PHP version selector if you have direct access to one. This article does not walk through any specific host's control panel, because the steps differ by host and a wrong generic instruction here is worse than none.
- Check the site immediately after the change: homepage, admin login, and the one plugin or feature you would most hate to lose.
- Check Site Health again. The PHP-version warning, if you had one, should be gone. If a different warning appears that was not there before, that is new information, not something to dismiss.
The one rule: never change PHP and WordPress on the same day
If you are behind on both (an old WordPress version and an old PHP version), the temptation is to fix both at once and be done with it. Resist it. If something breaks afterward, you will not know which change caused it, and you will be troubleshooting two variables instead of one. Raise PHP first, confirm the site is stable for at least a day, and only then run the WordPress update, using the pre-update checklist once you get there.
After the change: what to check
Beyond the basic homepage-and-login check, look specifically for anything that touches file uploads, forms, or a plugin that does heavier processing (image editing, PDF generation, scheduled tasks). Those are the categories most likely to depend on a PHP feature that changed between versions. If one of them misbehaves and you are not sure whether the cause was the PHP change or something else entirely, what actually happens during a WordPress update explains the update mechanism itself, which helps rule that variable in or out.
If the site goes white instead of showing a clear error after the change, here is the order to work through it. That is the more common outcome than an obvious error message, and it has its own procedure rather than the general troubleshooting sweep.
Related in this cluster
For the wider picture of what WordPress 7.x changed and why the PHP floor moved in the first place, see the site owner's guide to WordPress 7. Before you check your compatibility on the plugin side rather than the server side, how to find out which of your plugins will break covers that separate question.
Frequently asked questions
What is the minimum PHP version WordPress requires?
PHP 7.4 or greater, since WordPress 7.0. Support for PHP 7.2 and 7.3 ended at that release, according to wordpress.org's own requirements page.
How do I check what PHP version my WordPress site is running?
Go to Tools > Site Health > Info, expand Server, and look for PHP version. This is the number that matters, not a figure from your host's marketing page.
Is PHP 7.4 safe to keep using?
It still functions, but WordPress.org states it has reached end of life and no longer receives security fixes. The recommended version is 8.3 or greater.
Can I upgrade PHP myself, or do I need my host?
Many hosts offer a self-service PHP version selector in their control panel. If yours does not, it is a quick support request. This article does not walk through any one host's panel, since the steps differ by host.
Should I update WordPress and PHP on the same day?
No. Change one, confirm the site is stable, then change the other. If something breaks afterward, you will know which change caused it.
