WordPress recommends PHP 8.3 or greater. For a maintained site on WordPress 6.9 or later, test PHP 8.5 first; use PHP 8.4 if a plugin, theme, integration, or host is not ready for 8.5. Keep PHP 8.3 temporarily when it is security-supported and a documented dependency blocks the upgrade.
That is our selection rule, based on the official WordPress requirements and core compatibility matrix, checked 5 September 2026. Core support alone does not certify your complete site.
| Your situation | Candidate to test | Before going live |
|---|---|---|
| WordPress 6.9+; maintained plugins and host support 8.5 | PHP 8.5 | Verify forms, checkout, jobs, logs, and rollback on staging |
| WordPress 6.7+; an 8.5 dependency is not ready | PHP 8.4 | Record the blocker and test the same critical journeys |
| A supported site cannot yet pass on 8.4 or 8.5 | PHP 8.3 temporarily | Check upstream security support, assign the blocker, and set a review date |
| Old core, abandoned plugins, or a failing checkout | Resolve the dependency first | Back up, update on staging, and prove recovery before changing production |
Start with our PHP upgrade readiness checker to record the compatibility and recovery checks for your site.
Already know your target? Jump to the PHP 8.5 compatibility guide, PHP 8.4 checklist, or the upgrade test matrix below. If you need help testing and rolling out the change, our WordPress care service covers compatibility checks and rollback planning.
Current official baselines
The WordPress requirements page recommends PHP 8.3 or greater and notes that the legacy minimum is not the security recommendation.
The WordPress PHP compatibility matrix currently documents:
| WordPress branch | PHP 8.5 | PHP 8.4 | PHP 8.3 |
|---|---|---|---|
| WordPress 7.0 | Supported | Supported | Supported |
| WordPress 6.9 | Supported | Supported | Supported |
| WordPress 6.8 | Not supported | Supported | Supported |
| WordPress 6.7 | Not supported | Supported | Supported |
Check the live matrix before an upgrade; support status changes over time.
Core compatibility does not certify every plugin, theme, payment gateway, custom snippet, server extension, or hosting control panel.
A practical selection rule
Consider PHP 8.5 when
- the site runs WordPress 6.9 or later;
- the host supports the branch and its required extensions;
- maintained plugins and themes declare or demonstrate compatibility;
- staging tests, logs, scheduled jobs, and integrations pass;
- production has a tested rollback.
The WordPress and PHP 8.5 article covers that branch and the evidence boundary.
Consider PHP 8.4 when
- the site runs WordPress 6.7 or later;
- one component has not cleared PHP 8.5;
- the host supports 8.4 more maturely;
- the staging result is cleaner on 8.4.
See the WordPress and PHP 8.4 guide for the version-specific checklist.
Stay temporarily on PHP 8.3 when
- it is still security-supported upstream;
- the site cannot yet pass staging on a newer branch;
- a documented dependency blocks the move and has an active remediation plan.
“Temporarily” should include an owner and review date. An unsupported PHP branch should not become permanent because an abandoned plugin is convenient.
The upgrade test matrix
| Area | What to test |
|---|---|
| Public site | Key templates, navigation, search, forms, media, redirects, and error pages |
| WordPress admin | Login, editor, media library, updates, roles, and settings |
| Commerce | Product, cart, checkout, tax, shipping, payment callbacks, emails, and refunds |
| Scheduled work | WP-Cron, queues, imports, backups, and cache invalidation |
| Integrations | CRM, SMTP, analytics, APIs, webhooks, multilingual, and consent tools |
| Diagnostics | PHP and WordPress debug logs, web-server logs, deprecations, fatals, and warnings |
| Recovery | Backup restore and host-level PHP rollback |
A clean homepage is not enough evidence.
Elementor, WooCommerce, and extensions
Treat application compatibility separately from core:
- Elementor PHP compatibility should begin with Elementor’s official requirements and then test the actual add-ons and templates.
- WooCommerce compatibility includes extensions, payment and shipping plugins, subscriptions, and custom code, not only WooCommerce core.
- PHP extensions for WordPress should follow the official Hosting Handbook and the site’s real feature set. Enabling every module is not a safety strategy.
- WordPress 7 and PHP covers the core-version boundary; it does not replace full-stack testing.
Verify the current runtime carefully
WordPress Site Health and the hosting control panel are better sources than a remote fingerprinting tool. A public PHP-version checker can only report a version when the server exposes a detectable signal; “unknown” does not mean the site is not using PHP.
Webaloha.co itself currently runs Astro, not Elementor or PHP. That fact must not be used as evidence for a WordPress PHP recommendation.
Production rollout
- Inventory core, theme, plugins, must-use plugins, extensions, custom code, and integrations.
- Confirm the target PHP branch in the official WordPress matrix and upstream PHP support table.
- Update maintained components on staging.
- Back up files and database, and test the rollback path.
- Switch staging and run the full matrix above.
- Resolve fatals, warnings, deprecations, and missing extensions.
- Deploy during a monitored window.
- Re-test critical flows and watch logs, jobs, uptime, and transactions.
The recommendation is therefore conditional: use a current, security-supported PHP branch that WordPress supports and your actual stack proves ready for. Prefer evidence over slogans about the “fastest” or “most future-proof” version.
Frequently asked questions
What PHP version does WordPress recommend?
WordPress.org currently recommends PHP 8.3 or greater. That is a baseline, not an instruction to skip compatibility testing for the theme, plugins, custom code, host, and integrations on a specific site.
Should I use PHP 8.4 or PHP 8.5?
Use a PHP branch supported by WordPress and by your full stack. PHP 8.5 can be appropriate for WordPress 6.9 or later; PHP 8.4 is supported by WordPress 6.7 or later. Choose after staging tests and a rollback check.
Is the newest PHP version always best for WordPress?
No. A new supported branch may have a longer upstream runway, but plugins, themes, extensions, hosting tooling, and custom code can lag. The best production version is a supported branch that passes the site's critical tests.
How do I test a PHP upgrade?
Back up the site, reproduce production on staging, update maintained components, switch PHP, test public and admin flows, run scheduled jobs, review logs and deprecations, and confirm a fast rollback before changing production.
Does this Web Aloha website run on WordPress or PHP?
No. Webaloha.co is currently an Astro site. The PHP guidance applies to WordPress sites and is based on official compatibility documentation and site-specific testing, not this site's runtime.