Changing the PHP version behind a WordPress site can improve compatibility, security, and performance, but an untested upgrade may also expose plugin or theme problems. This reusable checklist explains how to choose a WordPress PHP version, test compatibility, change it through common hosting tools, and roll back safely if the site develops errors.
Overview
WordPress runs on PHP, while the active PHP version is provided by your web hosting environment. WordPress core, themes, plugins, the hosting control panel, and server extensions all need to work together. A site may appear healthy on one PHP branch and fail after switching to another because an older plugin uses removed functions, a theme contains incompatible code, or the server is missing a required extension.
There is no single PHP version that is correct for every WordPress installation. The practical choice is the newest version that is supported by your hosting platform and works with your WordPress core, theme, plugins, and custom code. Confirm the current recommendation in WordPress Site Health, your host’s documentation, and the documentation for important plugins before making a change. Treat labels such as “recommended,” “stable,” or “latest” as hosting-panel guidance that should still be validated against your site.
Before you begin, record the current PHP version and create a restorable backup of both the database and website files. A database-only backup is not enough if a theme, upload, configuration file, or custom integration must be restored. If the site is business-critical, use a staging copy rather than testing directly on production.
PHP version compatibility at a glance
| Area | What to check | Why it matters |
|---|---|---|
| WordPress core | Minimum and recommended PHP requirements shown by WordPress | Core may warn about an unsupported environment or behave unpredictably when requirements are not met. |
| Themes and plugins | Compatibility notes, release history, and support statements from each developer | Extensions can rely on PHP behavior that changed between branches. |
| Custom code | Theme functions, snippets, mu-plugins, scheduled tasks, and API integrations | Site-specific code is often missed during routine compatibility checks. |
| Hosting stack | Available PHP branches, extensions, PHP-FPM or handler settings, and resource limits | The hosting control panel may offer versions that differ between plans or server types. |
| Testing environment | Staging site using the same WordPress files, database structure, and PHP settings | A realistic test is more useful than checking only whether the homepage loads. |
PHP version compatibility is a moving target. A plugin update can resolve an issue, while a server change can introduce one. Keep a short record of the site’s PHP version, major extensions, last test date, and rollback method so another administrator can repeat the process.
Checklist by scenario
Before upgrading an existing site
- Confirm the current PHP version in WordPress Site Health or the hosting control panel.
- List active plugins, the active theme, must-use plugins, custom snippets, and external integrations.
- Update WordPress, the theme, and plugins through a tested maintenance process. Do not combine unrelated redesign work with the PHP change.
- Review plugin and theme documentation for PHP compatibility notes. Pay particular attention to abandoned or rarely updated extensions.
- Run a PHP compatibility checker where your host or development workflow provides one. Treat its results as a screening tool, not proof that the site is ready.
- Take and verify a full backup. Confirm where the backup is stored and how it would be restored.
- Clone the site to staging and select the target PHP version there first.
When testing on staging
- Open the homepage, key landing pages, posts, archives, search, menus, and forms.
- Log in as an administrator and test the editor, media uploads, plugin settings, scheduled tasks, and user roles.
- Test commerce, membership, booking, multilingual, analytics, newsletter, and payment workflows when they apply.
- Review PHP error logs, WordPress debug logs, web-server logs, and browser console messages. A site can look normal while background jobs are failing.
- Check that email notifications, webhooks, cron tasks, REST API requests, and third-party connections still operate.
- Compare page response and error behavior with the previous PHP version, without assuming that a speed change is caused only by PHP.
When changing PHP on production
- Choose a low-risk maintenance window and tell other administrators not to edit the site during the change.
- Confirm that the backup is recent and that you can access the hosting account independently of the WordPress dashboard.
- Use the hosting control panel’s PHP selector, MultiPHP tool, server configuration, or documented command-line method. Labels vary by provider.
- Change one environment at a time, record the old and new versions, and test immediately.
- Check both visitor-facing pages and authenticated workflows before declaring the upgrade complete.
If the upgrade causes errors
- Capture the exact error, affected URL, time of failure, and recent change. Preserve logs before clearing or rotating them.
- Use the host’s PHP selector to return to the previous working branch if the rollback is available and supported.
- If the site remains inaccessible, use the host’s file manager, SFTP, or command line to disable the suspected plugin or switch to a default theme, if you can do so safely.
- Restore files and database data only when a version rollback does not resolve the problem or the deployment changed more than PHP.
- Reproduce the issue on staging, identify the incompatible component, and update, replace, or isolate it before trying again.
What to double-check
Confirm that the PHP version was changed for the correct domain, subdomain, or application. Some hosting accounts assign different PHP handlers to different sites, and command-line PHP may use a different version from web requests. If your site uses a content delivery network, reverse proxy, cache, or managed WordPress layer, purge or bypass caches only after confirming that the application itself is healthy.
Check server extensions as well as the PHP branch. Image processing, internationalization, database connectivity, XML handling, and archive features may depend on extensions enabled by the host. A version change can also affect memory limits, execution time, OPcache behavior, file permissions, or scheduled task execution.
Review the error log instead of relying only on a blank page or a generic “critical error” message. Common symptoms include a fatal error naming a plugin or theme file, a white screen, failed background tasks, broken forms, missing images, unexpected redirects, or an admin screen that will not load. These symptoms identify where to investigate; they do not by themselves prove that PHP is the only cause.
For broader maintenance planning, keep the PHP change in the same operational record as backups, SSL checks, DNS changes, and hosting migrations. The website migration guide and hosting speed audit checklist can help when the version change is part of a larger hosting project.
Common mistakes
- Choosing the newest option without testing: Newer is a useful starting point, but compatibility must be checked against the complete application.
- Testing only the homepage: Checkout, forms, cron jobs, APIs, and admin actions may fail on less frequently visited paths.
- Skipping a full backup: A screenshot of settings or an automatic host snapshot is not a substitute for a known, restorable backup unless you have verified its scope and recovery process.
- Ignoring abandoned extensions: A plugin that has not been maintained may become the blocking component even when WordPress itself is ready.
- Changing several variables together: PHP, the hosting provider, a theme redesign, and multiple plugin updates should not be deployed as one untraceable event.
- Assuming rollback is automatic: Some hosts permit a PHP switch; others require support, a different handler, or a restoration plan. Confirm this before upgrading.
- Leaving an old branch in place indefinitely: Rollback is a safety measure, not a permanent compatibility strategy. Plan remediation for the component that prevents a supported upgrade.
When to revisit
Revisit this checklist before every PHP change, major WordPress or plugin update, theme redesign, hosting migration, or server-plan change. Review it during seasonal maintenance planning as well, especially before traffic-heavy campaigns or business periods when recovery time matters.
Update your internal notes whenever WordPress requirements, PHP support windows, hosting-panel labels, or major plugin compatibility guidance changes. Do not rely on a saved screenshot of a control panel: providers can move version selectors, rename handlers, or retire branches. When a site changes owners or administrators, repeat the backup and rollback test so the procedure is still usable.
For the next change, use this short action list: record the current version, check requirements, update components, back up files and database, test on staging, change production during a controlled window, inspect logs and workflows, and document the result. If the site cannot be tested or restored confidently, pause the upgrade and confirm the procedure with the hosting provider before proceeding.
