Most WordPress sites should run the newest PHP version that their WordPress core, theme, and plugins support, not the oldest one the server allows. WordPress publishes server requirements, and site owners should treat those requirements as a floor, not a target [source: WordPress.org]. A site can technically load on an older PHP version and still be a bad choice for security, speed, and plugin support.
TLDR: A modern WordPress site should usually aim for PHP 8.2 or PHP 8.3, after staging tests confirm that plugins and the active theme behave correctly. For example, a WooCommerce store on WordPress 6.5 and PHP 7.4 might first test PHP 8.2 on staging, run 20 checkout tests, then switch production only if payments, emails, and admin screens pass. In one typical maintenance case, moving from PHP 7.4 to PHP 8.2 can cut server response time by 10% to 25%, but one outdated plugin can wipe out the gain with fatal errors. The safe answer is simple: match WordPress core, PHP, plugins, and hosting as one stack.
Why PHP Compatibility Matters for WordPress
WordPress is written in PHP. Every page load, admin action, REST API request, scheduled task, and plugin hook depends on it. When PHP is too old, the site carries security risk. When PHP is too new for the installed code, the site may show warnings, broken forms, blank admin screens, or full fatal errors.
The catch is that WordPress core can support a PHP version while a plugin does not. A backup plugin, page builder, custom theme, or payment extension may use old PHP syntax. That makes the real compatibility question wider than “does WordPress support it?” It should be “does the full site support it?”
WordPress PHP Compatibility Matrix
The matrix below gives a practical planning view. It is meant for version choice and upgrade planning, not as a replacement for release notes or staging tests.
| WordPress Version | Minimum PHP Often Seen | Practical PHP Target | Recommendation |
|---|---|---|---|
| WordPress 6.6 and newer | PHP 7.2.24+ | PHP 8.2 or 8.3 | Best option for most maintained sites. Test PHP 8.4 only when the full stack is ready. |
| WordPress 6.4 to 6.5 | PHP 7.0+ | PHP 8.1 or 8.2 | Good upgrade base, but plugins should be checked before moving higher. |
| WordPress 6.2 to 6.3 | PHP 5.6.20+ | PHP 8.0 or 8.1 after testing | Core may run, but the site should update WordPress soon. |
| WordPress 5.9 to 6.1 | PHP 5.6.20+ | PHP 7.4 or 8.0 during transition | Upgrade core first, then move PHP higher. |
| WordPress below 5.9 | Varies | Do not treat as current | Plan a rebuild or controlled upgrade. Expect plugin trouble. |
Honestly, it feels like this should be simpler. A hosting panel may offer PHP 8.3 with one click, while the site still has a five-year-old plugin that breaks the media library. That is why the matrix should start the discussion, not end it.
How to Choose a Supported PHP Version
A WordPress administrator should use this order:
- Update WordPress core to the latest supported branch available for the site.
- Update plugins and themes, especially ecommerce, membership, SEO, caching, and form plugins.
- Check the host’s PHP options and pick a maintained PHP branch.
- Test on staging before changing production.
- Scan error logs after the switch.
PHP 7.4 and PHP 8.0 are no longer suitable long-term choices for most production sites because their official security windows have ended or passed in many environments [source: PHP.net]. Some hosts keep patched builds for enterprise customers, but that should not be confused with full ecosystem support.
Supported Does Not Always Mean Recommended
There is a big gap between minimum supported and best supported. WordPress may allow an older PHP version so that legacy sites do not break overnight. Plugin authors are less patient. Many now test mainly against PHP 8.1, 8.2, and 8.3.
For that reason, PHP 7.4 may appear to work until a plugin update lands. Then a harmless-looking update can trigger errors in payment pages, search filters, or admin AJAX tasks. Expect to waste time on this if staging is skipped. A failure that takes 30 seconds to detect on staging can take three hours to clean up on a live store.
Best PHP Choices by Site Type
- Simple brochure site: PHP 8.2 or 8.3 is usually a sound target after updates.
- WooCommerce store: PHP 8.2 is often a safer step than jumping straight to the newest branch.
- Membership site: Test login, renewals, password resets, and email sending before switching.
- Custom theme site: Review template functions, shortcodes, and any old custom plugin code.
- Agency-maintained site: Keep a written matrix for each client, with WordPress, PHP, theme, plugins, and host.
Warning Signs of PHP Compatibility Problems
Some failures are obvious. Others are sneaky. A site owner should watch for these signs after changing PHP:
- Fatal error messages in the browser or log files.
- White screen on the front end or admin panel.
- Checkout failure after payment submission.
- Broken forms that stop sending email.
- Deprecated warnings filling debug logs.
- Slow admin pages caused by repeated PHP notices.
Deprecated warnings do not always break the site today. Still, they are a clue. They show that code is aging and may fail on the next PHP jump.
A Safe PHP Upgrade Workflow
The safest workflow is boring, and that is the point. First, the administrator creates a full backup. Next, the site is copied to staging. Then WordPress, plugins, and themes are updated. After that, PHP is switched on staging only.
The test should include the real business paths. For a store, that means product search, cart, checkout, coupons, refunds, and transactional emails. For a lead site, that means every form, thank-you page, tracking script, and CRM connection.
After production switches PHP, logs should be checked for at least 24 to 48 hours. Caches should be cleared. Cron events should be reviewed. If the host allows quick rollback, the old PHP version should stay available during the first day.
Practical Rule for 2026 Planning
A maintained WordPress site should not plan around PHP 7.x unless there is a short migration reason. PHP 8.2 and PHP 8.3 are better targets for most sites. PHP 8.4 may be suitable when WordPress core, the theme, plugins, and hosting all confirm readiness.
The best matrix is not just WordPress versus PHP. It is WordPress + PHP + plugins + theme + hosting. If one part is stale, the whole stack becomes fragile.
FAQ
What PHP version is best for WordPress?
For many maintained sites, PHP 8.2 or PHP 8.3 is a strong choice. The exact pick depends on WordPress version, plugins, theme code, and hosting support.
Can WordPress run on old PHP versions?
Some WordPress versions can run on older PHP branches. That does not make those branches a good production choice. Old PHP can hurt security, plugin support, and performance.
Should a site jump straight to the newest PHP version?
Not always. A staging test should happen first. The newest PHP branch may expose old plugin code or custom theme issues.
What should be upgraded first, WordPress or PHP?
In most cases, WordPress core, plugins, and themes should be updated first. Then PHP should be changed in staging. This reduces surprise errors.
Why does a plugin break after a PHP update?
The plugin may use removed functions, outdated syntax, or code that creates fatal errors under newer PHP rules. This is common with abandoned plugins and old custom code.
Is PHP compatibility only a developer problem?
No. It affects store revenue, form submissions, admin access, search rankings, and security. A site owner does not need to write PHP, but the site still needs a tested PHP plan.
