A server runs several PHP versions at once, and each site chooses one. That is what MultiPHP Manager is for, and the reason people end up here is almost always the same: an application that requires a newer version than the site is running, or an old one that breaks on a newer version.
Set the version for a site
In cPanel, open MultiPHP Manager. Every domain on the account is listed with its current version.
Tick the domain, pick a version from the dropdown, apply. It takes effect on the next request. There is nothing to restart and no propagation delay.
Each domain is set independently, so an old application on one subdomain does not hold back the main site.
What "inherit" means, and why it bites
A domain set to inherit follows the server's default rather than holding a version of its own.
That sounds convenient and it means the version can change without you doing anything, when the server default moves. A site that worked yesterday and fails today, with no change on your side, is very often this.
Set an explicit version on anything you care about. Inherit is fine for a parked domain and a poor choice for a live site.
Which version to choose
Newer is faster and supported for longer. The current stable release is the right default for anything new, and modern WordPress runs on it comfortably.
Two reasons to hold back, and only two.
The application does not support it yet. Check before switching, not after.
A plugin or theme uses something removed in the newer version. This is the usual cause of a white screen after an upgrade.
Running a version that no longer receives security updates is not a neutral choice. It means known vulnerabilities in PHP itself stay unpatched on your site indefinitely.
Upgrade in the right order
The mistake is switching the live site first and finding out afterwards.
Update the application, themes and plugins to current versions. Then test on a staging copy at the new PHP version. Setting up a WordPress staging site sets out making one.
Then switch the live site, and check the error log rather than only the homepage. A fatal error on a checkout page does not show on the front page.
If something breaks, switch back. The change is instant in both directions, which makes this a low-risk experiment as long as you are watching.
Extensions belong to the version, not the account
This is the part that produces the most confusing symptom.
Each PHP version has its own set of extensions. Switching versions can therefore lose an extension the application depends on, and the error will name a missing function instead of a missing extension.
Check the extensions the application requires under the version you are moving to. cPanel exposes this in the PHP selector, where extensions are enabled per version rather than once for the account.
Settings are also per version
Memory limit, upload size and execution time are configured against a version. Switch versions and you inherit that version's values, not the ones you carefully raised on the old one.
An upload limit that reverts after a PHP upgrade is this, every time. Configuring PHP settings walks through setting them again.
When the version will not change
Three causes cover nearly all of it.
A handler line in .htaccess pinning a version, which overrides the selector. Look for a SetHandler or AddHandler line mentioning a PHP version and remove it.
You changed the wrong domain. Addon domains and subdomains are separate entries in the list.
You are reading a cached page. Check with a file containing phpinfo(), in a private window, and delete it immediately afterwards. It discloses more about the server than it should.
The command line is a different PHP
Worth knowing before it wastes an hour.
MultiPHP Manager sets the version for web requests. A cron job or a terminal command uses whatever php resolves to at the command line, which is often a different version entirely.
A script that works in the browser and fails in cron is usually this. Call the specific version's binary by its full path in the cron command rather than relying on phpSetting up cron jobs explains writing the command.
After switching
Check the error log for the first day, not just the first minute. Deprecation warnings appear immediately; fatal errors on rarely-visited paths appear when someone visits them.
Test the parts that touch other systems: payment, mail, file uploads. Those depend on extensions, which is exactly what a version change moves, and understanding cPanel error logs explains reading what turns up.
For a WordPress site specifically, the order of operations decides whether the switch is uneventful. For that, see How to Upgrade the PHP Version of a WordPress Site.
Find out which sites are on which version
Before changing anything, produce the list. On an account with several domains the versions drift apart and nobody remembers why.
grep -rn 'ea-php\|AddHandler\|AddType.*php' ~/public_html/.htaccess ~/public_html/*/.htaccess 2>/dev/null
php -v
find ~/public_html -maxdepth 2 -name '.htaccess' -exec grep -l 'php' {} \; 2>/dev/null
A handler line inside a directory overrides the panel for that directory and everything below it, which is why a site can run a version the panel does not report.
Those lines are usually left behind by an old migration or a plugin that wrote them years ago. Removing a stale one and setting the version properly in the panel is the fix, and doing it the other way around produces a setting that appears to save and has no effect.
Test the version before committing to it
Switching and then finding out is the expensive order, and a single file answers most of it in advance.
<?php phpinfo();
Placed temporarily in a directory set to the target version, that reports exactly what the site would run with: the version, the loaded extensions, the memory limit and the execution time.
Compare that list against the current version's before switching. A missing extension is the commonest cause of a site that breaks immediately after an upgrade, and it is visible here in ten seconds.
Delete the file afterwards. It describes your server in detail to anybody who finds it, and it is one of the first paths automated scanners request.
Plan the retreat before the advance
Switching version is instant and reversible, which makes it tempting to do without preparation. The reversal is only simple if you know what to reverse to.
Write down the current version, the current memory and execution limits, and the extension list, before touching anything. Then switch at a time when you can watch the site rather than at the end of the day.
php -m > /tmp/ext-before.txt
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/
tail -20 ~/logs/example.com.error.log
Check the front page, one dynamic page and the administration area, then read the error log rather than assuming silence means success. A fatal error on a page nobody visited yet is still a fatal error, and the log is where it appears first.
