Choosing a PHP version is a hosting maintenance decision, not a setting to change blindly. This guide explains how to select a compatible PHP release, check WordPress themes and plugins, change PHP version in cPanel or another hosting panel, and recover safely if your site shows a blank page, a 500 error, or an extension conflict.
Overview
PHP is the server-side language used by many content management systems, including WordPress, as well as custom applications, forums, ecommerce platforms, and development frameworks. Your PHP version affects compatibility, security maintenance, performance, and which extensions your website can use.
As a general rule, use the newest PHP version that your application, themes, plugins, scripts, and hosting environment have been tested with. Do not choose a version solely because it is the newest option in your control panel. A newer runtime can expose old code that relied on removed functions, changed behavior, or unsupported extensions.
| Website situation | Practical PHP choice | What to verify |
|---|---|---|
| Recently updated WordPress site | Use the newest PHP 8.x release supported by your host and tested by your plugins and theme. | Check the current WordPress requirements and each plugin's compatibility notes. |
| Older WordPress site or neglected installation | Test a supported PHP 8.x release in staging before changing production. | Update or replace abandoned plugins, themes, and custom snippets first. |
| Custom PHP application | Follow the framework and application dependency requirements rather than using a generic recommendation. | Review composer packages, database drivers, extensions, and deployment documentation. |
| Legacy script that cannot be updated immediately | Use the oldest still-supported version that runs the application, while planning a migration. | Confirm the host's support policy and avoid treating an obsolete runtime as a permanent solution. |
PHP support changes over time. Hosting panels may label versions as “PHP 8.3,” “ea-php83,” “alt-php83,” or simply “8.3.” These labels identify the runtime family, but the host may also apply its own patch level and extension set. Before an upgrade, check the host's current availability, the PHP project's support information, and the requirements published by your CMS or framework. This keeps the table above useful even as new PHP releases appear and older branches reach end of support.
Checklist by scenario
If you run WordPress
- Record the current version. Note the PHP version, WordPress version, active theme, important plugins, and hosting panel settings.
- Update carefully. Apply available WordPress, theme, and plugin updates before testing PHP, but avoid making many unrelated changes at once.
- Check compatibility notes. Look at the plugin and theme documentation for supported PHP versions, especially for payment, membership, page-builder, caching, and security tools.
- Create a backup. Keep both the website files and database. A backup stored only on the same hosting account may not help if the account or filesystem becomes inaccessible.
- Test a staging copy. Open the homepage, contact forms, login screen, checkout, search, menus, and any logged-in features after changing PHP.
- Change production during a quiet period. Tell site users about planned maintenance if the website handles orders, registrations, or submissions.
If you run a custom PHP script
- Check the application's documented PHP range and dependency lock file.
- Confirm required extensions, such as database drivers, cURL, mbstring, OpenSSL, XML, GD, or Imagick, are available under the target version. The exact list depends on the application.
- Test database connections, file uploads, scheduled tasks, API calls, authentication, and email delivery.
- Review error logs after the test. A page that appears to work can still produce warnings or failed background jobs.
- Deploy the same PHP version and extension configuration to production rather than testing one environment and deploying another.
How to change PHP version in cPanel
The labels differ between hosts, but the process is usually similar:
- Sign in to cPanel and open MultiPHP Manager, Select PHP Version, or a similarly named tool.
- Select the domain or subdomain. Confirm that you are changing the correct document root, particularly if the account hosts several sites.
- Choose the target PHP version and save or apply the change.
- Open the site in a private browser window. Test both the public pages and the administration area.
- Review the PHP error log and application log. If the site fails, return to the previous version while investigating.
Some hosts manage PHP at the account, domain, directory, or server level. On managed WordPress hosting, the provider may expose the setting in a custom dashboard instead of cPanel. If no PHP selector is available, ask the host which runtime is assigned and whether a staging environment is included.
What to double-check
- Backups are restorable. Confirm that the latest backup contains the database and uploads, and know how to restore it. See the website backup and restore workflow before making a high-impact change.
- DNS is not the cause. A PHP change normally affects the server running the site, not domain records. If the domain points to the wrong server, review the domain and hosting connection guide.
- CLI and web PHP may differ. A hosting account can use one PHP version for web requests and another for command-line tasks or cron jobs. Check both if you use Composer, WP-CLI, queues, or scheduled scripts.
- Extensions match the version. An extension enabled for one PHP branch may be unavailable or configured differently in another. Compare the old and new extension lists.
- Database connectivity works. Test the application database credentials, driver, character encoding, and permissions. A PHP upgrade can reveal a driver or configuration problem that was previously hidden.
- Resource limits are adequate. Check memory limits, execution time, upload limits, and process limits. For wider capacity issues, use the hosting resource usage guide.
- Email still functions. Test contact forms and transactional messages. PHP runtime changes may affect mail libraries, certificates, or authentication settings, even when DNS remains unchanged.
Common mistakes and troubleshooting steps
Blank page or “critical error”
This often indicates a fatal PHP error. Temporarily disable the most recently changed plugin, theme, or custom code, then inspect the PHP and application logs. If you cannot access the dashboard, use the host's file manager or database tools to disable the suspected component. Restore the previous PHP version if necessary, then update or replace the incompatible code.
Deprecated-function warnings
A warning about a deprecated function means that code is using an older API. On a production site, avoid displaying these warnings to visitors because they can reveal paths or disrupt page output. Enable logging rather than public display, identify the responsible plugin, theme, library, or custom file, and update it. Do not suppress every warning permanently; use the message to plan remediation.
500 Internal Server Error
Check the error log first. Common causes include incompatible code, a missing extension, invalid rewrite rules, incorrect file permissions, exhausted memory, or a PHP handler problem. Change one setting at a time so the cause remains identifiable. If the error begins immediately after the PHP change and disappears after rollback, preserve the log entry and send it to the host or developer.
Extension conflict
If the application reports that a module is missing, compare the required extension list with the options enabled in the hosting panel. Shared hosting may not allow customers to install arbitrary modules. In that case, ask the provider whether the extension can be enabled or select an application configuration that does not require it.
Rollback does not fix the site
Rollback may not reverse database migrations, changed configuration files, caches, or plugin updates made during the same maintenance window. Clear application and server caches, restore the affected files or database from the pre-change backup if appropriate, and review every change made. For a broader move or failed recovery, consult the website migration guide.
When to revisit your PHP version
Revisit this checklist before major CMS, theme, plugin, framework, or database updates; after moving to new hosting; when your host adds or removes runtime options; and whenever the PHP project publishes a new branch or marks an older branch end-of-life. It is also sensible to review the setting before a busy seasonal period, after a security incident, or when your monitoring shows unexplained errors.
Keep a short maintenance record containing the date, old and new PHP versions, enabled extensions, test results, backup location, and rollback decision. This makes future upgrades faster and gives support staff useful evidence. You can also monitor availability using an uptime and incident log workflow.
Before your next upgrade, complete this final action list:
- Check the current support status of the PHP branches offered by your host.
- Confirm CMS, theme, plugin, framework, and dependency compatibility.
- Make and test a complete backup.
- Record the current PHP version and extension settings.
- Test the target version on staging or a duplicate site.
- Change production, test critical functions, and watch the logs.
- Rollback promptly if the site fails, then investigate from the recorded error.
The best PHP version is the newest supported version that your complete website—not just its core software—can run reliably. Treat the change as a small release, keep a rollback path, and revisit the decision whenever your software or hosting environment changes.
