Changing PHP can be one of the highest-impact maintenance steps on a WordPress site. It can improve the platform you are running on, but a version switch also affects every active plugin, the theme, custom code, scheduled tasks and integrations that execute PHP.
The useful question is therefore not simply “Does WordPress support this PHP version?” A safer question is: does WordPress support it, do my plugins and theme declare compatible requirements, and have I tested the workflows that matter?
The free WordPress PHP Requirements Checker helps with the first layer of that decision. It compares a target PHP version with WordPress’s current core minimum and recommended baseline, then lets you add the declared requirements of a plugin or theme. This guide explains what those numbers mean—and what they cannot tell you.
WordPress minimum PHP vs recommended PHP
As of WordPress 7.1, the absolute core minimum is PHP 7.4. The WordPress Hosting Team notes that WordPress 7.1 is compatible with PHP 7.4 through PHP 8.5, while older PHP branches are retained for backward compatibility even when they have reached upstream end-of-life.
That is different from the public WordPress.org hosting recommendation. WordPress.org currently recommends PHP 8.3 or greater, MariaDB 10.11+ or MySQL 8.0+, and HTTPS. The requirements page also warns that legacy versions may expose a site to security risks.
This distinction matters. A minimum answers “Will WordPress core refuse this environment?” A recommendation is a better starting point for a modern production stack. Neither one automatically certifies all of your plugins, theme or custom code.
How plugins declare their PHP requirements
A WordPress plugin’s main PHP file can contain headers such as Requires PHP and Requires at least. The first states the plugin’s minimum PHP version; the second states its minimum WordPress version.
Modern WordPress reads these requirements from the plugin’s main PHP file. The Plugin Handbook notes that since WordPress 5.8, the readme is no longer the source used for these requirement checks. WordPress core’s validate_plugin_requirements() function evaluates the plugin’s declared WordPress and PHP requirements, along with declared plugin dependencies.
For example, if a plugin declares Requires PHP: 8.1, a server running PHP 8.0 does not meet that declared minimum even though WordPress core itself may run there.
How themes declare PHP requirements
The same idea applies to themes. WordPress validates a theme’s Requires PHP and Requires at least information from the theme’s style.css headers.
This is easy to overlook during a PHP migration. A site can have dozens of plugins but only one active theme, so people sometimes check the plugin list carefully and assume the theme will be fine. Custom themes deserve the same review—especially older themes that contain legacy PHP patterns or bundled libraries.
Why a green requirement check is not proof of compatibility
Declared minimums are valuable, but they are metadata, not an execution test. A plugin author might support PHP 7.4 as a minimum while also supporting newer releases. Another plugin may omit a requirement entirely. Custom code usually has no WordPress.org metadata to inspect.
A simple version comparison also cannot see whether a particular checkout callback, PDF library, payment SDK, import routine or admin-only screen uses behavior that changed in a newer PHP release.
That is why the WPToolix checker deliberately reports declared constraints without calling the result a full compatibility scan.
A practical pre-upgrade checklist
Start by recording the current PHP and WordPress versions. Then inventory the active theme, must-use plugins, ordinary plugins and any custom code that executes on the site. Check their documented minimums and current support status.
Next, choose a target PHP version that makes sense for your hosting environment. Avoid treating the oldest version WordPress can technically run as the target merely because it passes a minimum check.
Use the WordPress PHP Requirements Checker for quick comparisons. If a plugin requires PHP 8.2 and the destination is PHP 8.1, that is an immediate blocker you can resolve before touching production.
Test the PHP change on staging
The most useful compatibility test is still the real application. Clone the site to a staging environment that resembles production, take a fresh backup, and change PHP there first.
Do not stop after loading the homepage. Test wp-admin, login/logout, forms, search, media uploads and any custom admin screens. On WooCommerce sites, test product pages, cart calculations, checkout, payment callbacks where safely possible, emails, refunds or subscriptions when those workflows are relevant.
Also test background behavior. Cron callbacks, imports, feed generators and API synchronization may not fail while you are browsing the site. The WordPress Cron Generator explains the scheduling side of background tasks, but existing scheduled callbacks still need runtime testing after a PHP change.
Check logs, not just visible pages
A page can appear normal while PHP is recording warnings or deprecations. During staging verification, inspect the server’s PHP error log and, when WordPress debugging is intentionally enabled in a safe environment, review the WordPress debug log.
The WordPress Debug Log Analyzer can group repeated messages and help separate fatal errors, warnings, notices and deprecations. A clean browser screen is not a substitute for checking the logs.
Understand the difference between fatal errors and deprecations
A fatal error that breaks checkout or wp-admin is an obvious release blocker. A deprecation may not break the request today, but it can identify code that needs maintenance before a future PHP change.
Prioritize by impact: fatal and uncaught errors first, then repeated warnings affecting real workflows, then deprecations and lower-severity notices. The exact response depends on the code path and whether the message comes from your code, a maintained dependency or an abandoned component.
Do not confuse PHP version with PHP memory
“Allowed memory size exhausted” is a PHP error, but it does not automatically mean the PHP version is incompatible. It means the request reached its memory ceiling.
If memory is the actual constraint, investigate why the request is consuming so much and review the relevant limits. The WordPress Memory Limit Generator can help plan WordPress memory constants, but raising a limit should not be used to hide an uncontrolled query, import or loop.
What about PHP extensions?
Version numbers are only part of the runtime. WordPress and plugins can depend on PHP extensions and server capabilities. An environment may run a suitable PHP version while missing an extension required by an image library, internationalization feature, encryption routine or third-party SDK.
This is another reason a browser-based version checker should remain narrow. It can tell you that 8.1 is lower than a declared 8.2 requirement; it cannot inspect modules installed on a server you have not connected to it.
Plan a rollback before production
Before switching production PHP, know how to restore the previous version quickly. Hosting panels differ: some allow a PHP version switch in seconds, while managed environments may require a deployment or support action.
Keep a current backup, know which PHP version was working, and avoid combining a PHP switch with several unrelated production changes. Smaller change sets make failures easier to diagnose.
Plugin and theme developers: declare requirements accurately
If you maintain a plugin, the official Plugin Handbook supports Requires PHP and Requires at least in the main plugin file. WordPress uses those values during requirement validation, so they should reflect what the released code actually supports.
Do not choose a low number purely to make a compatibility badge look broad. Equally, do not raise the minimum casually if the code still works on a supported lower version. Your declared minimum is part of the upgrade information site owners rely on.
A simple decision model
For a production upgrade, I would separate the decision into four gates:
- Core gate: Does the target meet WordPress core’s requirement and make sense relative to the current recommended baseline?
- Declared-requirements gate: Do the active plugins and theme meet their stated PHP and WordPress requirements?
- Runtime gate: Do important frontend, admin, ecommerce and background workflows work on staging?
- Operations gate: Are logs acceptable, backups current and rollback understood?
A failure at any gate gives you a concrete next step. That is more useful than asking whether a PHP version is simply “compatible with WordPress.”
Frequently asked questions
What is the minimum PHP version for WordPress 7.1?
The WordPress Hosting Team lists PHP 7.4+ as the absolute minimum for WordPress 7.1. That does not make PHP 7.4 the recommended production choice.
What PHP version does WordPress.org recommend?
The current WordPress.org requirements page recommends PHP 8.3 or greater.
Can WordPress block an incompatible plugin?
WordPress has requirement-validation logic that uses a plugin’s declared Requires PHP and Requires at least headers. This helps with declared incompatibilities, but it cannot discover every runtime incompatibility in plugin code.
Does a plugin’s readme control its PHP requirement?
Not for modern WordPress requirement validation. The official Plugin Handbook says that since WordPress 5.8, requirement headers are parsed from the plugin’s main PHP file rather than its readme.
Should I update PHP directly on a live WooCommerce store?
A staging-first change is safer. WooCommerce stores have more business-critical workflows to exercise, including cart, checkout, payment, email and background processing. Test those before the production switch.
Use requirements as a filter, then verify the application
PHP requirement metadata is excellent for finding obvious blockers early. It is not a replacement for staging, workflow testing and log review.
Start with the free WordPress PHP Requirements Checker, resolve any declared version mismatch, then test the actual site. That combination gives you a much stronger upgrade decision than either a version number or a successful homepage load on its own.