Free tools Windows power users keep installed
One-click scans. No signup required.
Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
WordPress recommends PHP 8.3 or newer as of August 18, 2026. For a current site, PHP 8.4 or 8.5 is a sensible target if the host and the site’s plugins, theme, custom code, and integrations have been tested with it. WordPress 7.0 can still run on PHP 7.4, but that PHP branch is obsolete and is not a safe target for a new production setup.
Before switching, check the PHP version actually serving the site, create and verify a restorable backup, test the target on staging if available, and record how to roll back. WordPress core compatibility alone does not guarantee that every component of your site will work.
What PHP version does WordPress recommend?
WordPress’s current recommendation is PHP 8.3 or newer. That is an ecosystem recommendation, not a promise that every plugin or theme supports every newer PHP release. WordPress 7.0’s minimum supported version is PHP 7.4; “minimum supported” describes a compatibility floor, not a secure or advisable production target. See WordPress requirements, the WordPress Core PHP support clarification, and the WordPress/PHP compatibility matrix.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →PHP is the server-side language WordPress primarily uses: the server runs PHP to build pages and responses for visitors. Its version affects security support, language features, and compatibility, but is separate from the WordPress application version, database, web server, and hosting plan. WordPress’s PHP overview explains its role in performance and hosting.
#1 Best Overall
The table reflects PHP and WordPress guidance as of August 18, 2026. PHP.net’s active and security-support dates describe the PHP branch lifecycle; WordPress’s recommendation describes its preferred baseline. These are related but different measures.
| PHP branch | PHP lifecycle status on August 18, 2026 | WordPress compatibility guidance | Practical choice |
|---|---|---|---|
| 8.5 | Active support through December 31, 2027 | Fully supported by WordPress 6.9 and 7.0 | Choose if the host and full site stack pass testing. |
| 8.4 | Active support through December 31, 2026 | Fully supported by WordPress 6.8 and later | A strong production option for a maintained site. |
| 8.3 | Security support through December 31, 2027 | WordPress’s minimum recommended version | A compatibility-first target for older sites. |
| 8.2 | Security support through December 31, 2026 | Can run WordPress, but is below the current recommendation | Transitional only; plan an upgrade. |
| 8.1 | Active support has ended | May run some WordPress versions | Upgrade to a supported branch. |
| 8.0 and older | Obsolete or unsupported by PHP | May remain in use for legacy compatibility | Upgrade promptly; do not treat continued operation as support. |
| 7.4 | End-of-life | Minimum supported by WordPress 7.0 | Backward compatibility only; do not choose for a new production site. |
PHP generally receives two years of active support followed by two years of security-only support. Check the live PHP supported versions table because status and dates change over time.
Should you choose PHP 8.3, 8.4, or 8.5?
Use the newest stable branch that the host and the complete site stack have passed in testing. A core version being compatible does not certify plugins, themes, page builders, payment gateways, or custom code. The compatibility matrix and PHP lifecycle table are useful starting points, but component-level testing decides whether a site is ready.
Recommended Free Tools
- Choose PHP 8.5 when it is available from the host and the site’s plugins, theme, custom code, and integrations have been tested. It has the longest support runway of these three branches as of August 18, 2026.
- Choose PHP 8.4 for a maintained site whose components support it, especially if you prefer not to move immediately to the newest branch.
- Choose PHP 8.3 as a cautious step for a legacy site or an upgrade from an older branch when compatibility is uncertain. It meets WordPress’s current recommendation.
Do not stay indefinitely on an obsolete branch just because WordPress core still runs on it. Conversely, newer PHP is not automatically faster for every site: results depend on workload, database queries, caching, traffic, and host configuration. The WordPress Hosting Handbook’s server-environment guidance covers the broader hosting context.
How to check the PHP version serving your site
In the WordPress dashboard
- Go to Tools → Site Health.
- Open the Info tab.
- Expand Server and check the PHP version and server details.
Labels or displayed details can vary with the WordPress release, permissions, and host. WordPress also documents its PHP-version detection through wp_check_php_version().
In your hosting control panel
Look for the selected site or domain’s PHP or runtime settings. Common locations include cPanel → MultiPHP Manager, Plesk → PHP Settings, or a managed host’s environment settings. The host determines which PHP versions are available and may apply a change per site, per account, or per environment.
From the command line
On a shell, php -v reports the command-line PHP version. For WP-CLI, wp cli info shows CLI environment details; wp --info reports WP-CLI environment information, and wp site health can run Site Health checks. Refer to the WP-CLI environment information command.
Command-line PHP can use a different binary or configuration from the PHP runtime serving website requests. Verify the web version in Site Health or the host’s site settings; a result from php -v alone is not proof of the public site’s version.
What to do before changing PHP
Prepare a rollback before touching the production runtime. A backup is useful only if it can be restored, so confirm the restoration route rather than relying on a backup label in the hosting dashboard.
- Confirm that the host offers the target branch and that it supports the site’s required PHP extensions.
- Record the current PHP version and find out whether the host can switch back, how quickly, and whether the change affects other sites on the account.
- Create a full database and file backup, including
wp-content, custom configuration, and any server-specific files. Verify that it is restorable. - Update WordPress core, plugins, and themes through their normal maintenance channels. Replace or remove abandoned extensions and check compatibility notes from major plugin and theme maintainers.
- If available, clone the site to staging and test the target PHP version there before changing production.
- Confirm that you can reach the hosting panel or use SFTP if WordPress itself becomes unavailable. For a business-critical site, schedule the change during a quieter period.
- Ask whether the host restarts PHP workers or refreshes OPcache during a version switch.
WordPress’s PHP update guide also stresses backing up and checking theme and plugin compatibility. Keep the current PHP version available as a rollback option, not as a substitute for fixing incompatible code.
How to update PHP through a hosting provider
Control-panel labels differ, so use the host’s instructions for the specific site rather than assuming that every account has the same menu.
- Sign in to the hosting account and select the correct domain, site, or environment.
- Open the area labelled PHP, runtime, server, or site settings.
- Select the tested PHP branch—8.3, 8.4, or 8.5, for example—and apply or save the change.
- Wait for the host to apply the runtime change and restart services if required.
- Check the version in WordPress Tools → Site Health → Info → Server.
- Test the dashboard and public site, then inspect relevant PHP, web-server, WordPress, and security logs.
If you cannot find a PHP selector, ask the host which PHP versions are available, whether the change is per site or account-wide, whether staging and rollback are available, which extensions are enabled, and which runtime or handler the site uses (such as PHP-FPM). If the site is on an obsolete branch, ask whether the provider offers a supported extended-security option while you plan the upgrade.
Updating PHP on a VPS or dedicated server
There is no safe universal package command for a production server: package names, repositories, operating systems, PHP-FPM services, and web-server integrations vary. Do not replace system PHP packages by guesswork.
- Identify the operating system, package source, web server, and PHP handler, then follow the provider’s migration documentation.
- Install the target branch and the extensions the site actually needs.
- Update the PHP-FPM pool or web-server handler, then restart the relevant services using the operating system’s documented procedure.
- Verify both CLI PHP and the web-server runtime. Check permissions, OPcache, cron, queues, image processing, mail, and database connectivity.
Recommended WordPress PHP settings
The PHP branch is the main version decision, but extensions and runtime limits also matter. Requirements depend on WordPress, the site’s plugins and themes, and hosting configuration. Use Site Health and the host’s documentation to diagnose a missing capability rather than enabling everything indiscriminately.
Extensions
Common WordPress environments should provide extensions including mysqli, curl, dom, exif, fileinfo, hash, imagick or gd, json, mbstring, openssl, pcre, xml, and zip. The exact needs vary; image workflows and particular plugins may require a specific extension. Consult the Hosting Handbook’s recommended extensions and ask the host to confirm availability.
Memory limit
Do not copy a single memory value without considering the host and workload. memory_limit is the PHP runtime cap, while WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT are WordPress targets for frontend and administration requests. WooCommerce, page builders, imports, and image processing can need more headroom than a small brochure site. If a task exhausts memory, check logs and the host’s actual limits before changing a value.
Uploads and request limits
These PHP settings govern different constraints and should match the site’s upload and processing needs:
upload_max_filesize: maximum size of an individual uploaded file.post_max_size: maximum size of the entire POST request; it should be at least as large asupload_max_filesize.max_execution_timeandmax_input_time: time allowed for script execution and request input processing.max_input_vars: number of input variables PHP accepts.max_file_uploads: number of files PHP accepts in one request.
Increasing a limit may help a large upload or import, but will not fix slow code, a memory leak, poor database queries, or a gateway timeout.
OPcache and error handling
OPcache can reduce repeated PHP compilation by caching compiled scripts. Hosts commonly manage it; available memory, PHP-FPM workers, deployment practices, and cache invalidation determine appropriate settings. Ask the host whether a version switch restarts the runtime and refreshes OPcache instead of applying aggressive values without knowing the server’s resources.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesOn production, log errors rather than displaying them to visitors. For a controlled diagnosis, WordPress documents these temporary settings in its debugging guide:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Use them temporarily, preferably while diagnosing on staging, and turn off verbose debugging after the issue is resolved.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What to test after changing PHP
Test real site workflows, not just whether the homepage loads. A quiet failure may affect a background task or transaction without visibly breaking a page.
- Open the dashboard and edit or save a page, especially if the site uses a page builder.
- Check the homepage, key landing pages, search, login, logout, password reset, and user registration.
- Submit forms and confirm email delivery; upload media and verify image generation.
- Check scheduled posts, cron tasks, REST API requests, XML sitemaps, caching, and CDN behavior.
- For WooCommerce, test cart, checkout, payment, refunds, taxes, shipping, and transactional email.
- For membership or subscription sites, test access rules and recurring billing; test third-party APIs and webhooks used by the site.
- Review Site Health, PHP and server logs, uptime monitoring, and any relevant background-job or security logs.
What to do if the site breaks
White screen or HTTP 500
Possible causes include an incompatible plugin or theme, a fatal error caused by changed PHP behavior, a missing extension, memory exhaustion, a misconfigured PHP handler, or file ownership and permissions. Use the host panel to switch back to the recorded PHP version, then inspect PHP and web-server error logs for the specific failure. Update, disable, replace, or repair the component named in the error; test the fix on staging before trying the upgrade again.
WordPress admin is unavailable
Use the hosting panel’s PHP selector first if the runtime change caused the outage. If the error points to a plugin and the dashboard is inaccessible, use the host file manager or SFTP to rename that plugin’s directory temporarily. If WP-CLI is configured for the intended site, you can deactivate the named plugin or, as a temporary isolation step, all plugins:
wp plugin deactivate plugin-slug
wp plugin deactivate --allConfirm the command is operating on the correct WordPress installation before running it. Re-enable plugins methodically after identifying the incompatible component.
A plugin fails without an obvious page error
Review PHP and WordPress debug logs, the plugin’s compatibility notes, required extensions, REST API and AJAX responses, cron or background processing, and whether the plugin is still maintained. A page that appears normal does not prove that checkout, webhooks, scheduled jobs, or administrative actions still work.
The site works but performance worsens
A PHP upgrade cannot by itself fix slow database queries, excessive autoloaded options, uncached dynamic pages, poor plugin architecture, external API delays, insufficient PHP-FPM workers, limited CPU or RAM, or cache invalidation issues. Profile the bottleneck and check host resources rather than treating a PHP version change as a complete performance solution.
Rolling back can restore service, but it should be a recovery step. The durable fix for an incompatible component is to update, replace, patch, or remove it, then move the site to a supported PHP branch after testing.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
