You logged into cPanel to bump your PHP version — maybe a plugin demanded PHP 8.1, maybe you just want off an end-of-life version — and either the site went white, or a support ticket told you it's overdue. Either way, changing PHP version is a five-second click in cPanel, but it can quietly break a site that was depending on old behavior. Here's how to do it without the surprise.
Symptom: Site Breaks (or a Plugin Refuses to Work) After a PHP Change
There are really two situations that bring people here:
- You need to go up. A plugin, theme, or WordPress core update says it requires PHP 8.0+ and your account is still sitting on 7.4, which most current LTS support windows have already dropped.
- You already switched, and now something's broken. A white screen, a
Fatal error: Uncaught Error: Call to undefined function, or a plugin settings page that just won't save.
Both are solved the same way: understanding what MultiPHP Manager actually changes, and testing the switch properly instead of flipping it live and hoping.
Cause: What a PHP Version Actually Controls
PHP version isn't just a number in a dashboard — it changes real behavior your code depends on:
- Removed functions. PHP 8 dropped several functions that were already deprecated in 7.x (like the old
each()function, and variousmysql_*calls that should've beenmysqli_*for a decade). Old plugins that never got updated will fatal-error the moment you switch. - Stricter type handling. PHP 8 is much less forgiving about passing the wrong data type to a function. Code that worked “by accident” in 7.x can throw a
TypeErrorin 8.x. - Different default
php.inivalues. Each PHP version on your account has its own settings formemory_limit,upload_max_filesize,max_execution_time, and which extensions are enabled by default. - Extension availability. An extension enabled on PHP 7.4 (say, an older image or mail library) may not have a build for 8.2, so a feature that quietly relied on it stops working.
In short: the version number is really a bundle of function availability, strictness rules, and default settings, and any one of those can be the thing that breaks.
Fix: Changing PHP Version With MultiPHP Manager
This is the main tool for the job in cPanel:
- Log into cPanel and open MultiPHP Manager (under the Software section).
- You'll see a table listing every domain and addon domain on the account, with its current PHP version next to it.
- Tick the checkbox next to the domain you want to change (or select multiple if they should all move together).
- Pick the new version from the dropdown at the top and click Apply.
That's it — no restart, no downtime for the change itself. The next request to that domain runs on the new version. This is also why per-domain control matters: if you host three sites under one cPanel account, you don't have to move all of them at once. Test the risky one on its own domain first.
If you only have a single domain and don't see the per-domain table, look for MultiPHP INI Editor instead — that's where you adjust individual php.ini directives like memory limit once the version itself is set.
Fix: What To Do If the Site Breaks Right After Switching
If you flipped the version and got a white screen or fatal error, don't panic and don't immediately revert — first find out what actually broke:
- Turn on WordPress debug logging. In
wp-config.php, setdefine('WP_DEBUG', true);anddefine('WP_DEBUG_LOG', true);, then reload the page and checkwp-content/debug.log. It will usually name the exact plugin file and function that failed. - Check cPanel's error log (Metrics → Errors, or
~/logs/domain.com/error_logif you have SSH access) for the same fatal error with a file path and line number. - Deactivate plugins one at a time via File Manager by renaming the offending plugin's folder inside
wp-content/plugins/(add “-disabled” to the end). WordPress treats a renamed folder as deactivated without you needing admin access. - Check your theme too, not just plugins — older custom themes are just as likely to use deprecated PHP syntax.
If the error log points to a specific extension issue rather than your code, go back to MultiPHP Manager, click the gear/wrench icon next to your PHP version, and confirm the extension you need (e.g. imagick, intl, opcache) is actually enabled for that version — extensions are toggled per PHP version, not globally.
When Reverting Is the Right Call
If it's a production site getting live traffic and the fix isn't a two-minute plugin update, revert to the previous PHP version in MultiPHP Manager immediately, then do the real upgrade work on a staging copy where a broken page doesn't cost you customers.
Picking the Right Version to Move To
| PHP Version | Status | Recommendation |
|---|---|---|
| 7.4 and earlier | End of life, no security patches | Move off it — this is a real security exposure, not just a compatibility nice-to-have |
| 8.0 / 8.1 | Security fixes only or approaching EOL | Acceptable short-term, but plan the next move |
| 8.2 / 8.3 | Actively supported | Good target for most current WordPress installs and plugins |
Before committing to a target version, check your theme and every active plugin's “Requires PHP” field on their changelog or the WordPress.org plugin page. If even one critical plugin caps out at 8.1, that's your ceiling until it's updated — not 8.3.
Prevention: Test Before You Touch Production
- Use a staging subdomain. If your plan includes one, clone the site there, switch that subdomain's PHP version first, and click through the site — homepage, a blog post, checkout if it's WooCommerce, and the admin dashboard.
- Update plugins and WordPress core before switching, not after. Most compatibility fixes for newer PHP already shipped in recent plugin releases.
- Take a backup first. A full cPanel backup (Files + database) takes a couple of minutes and means a bad switch is a restore away from fixed, not a fire drill.
- Schedule it for low-traffic hours even though the switch itself is instant — if something is broken, you want the smallest possible window before you notice.
Switching PHP versions is routine maintenance, not a gamble, as long as you check compatibility first and have a backup ready as your undo button.
Frequently Asked Questions
Will changing PHP version in cPanel cause downtime?
No. The switch itself applies to the next request — there's no server restart or outage window. Any “downtime” you see afterward is the site erroring out because of a compatibility issue, not the switch itself.
Can I run different PHP versions for different websites on the same cPanel account?
Yes. MultiPHP Manager lets you set the PHP version per domain and per addon domain independently, so one site can run 8.2 while another stays on 8.1 until it's updated.
How do I know which PHP version my WordPress site actually needs?
Check Tools → Site Health inside wp-admin — it lists your current PHP version and flags it if it's below WordPress's recommended minimum. For individual plugins, check the “Requires PHP” line on their WordPress.org page or changelog.
What's the difference between MultiPHP Manager and MultiPHP INI Editor?
MultiPHP Manager sets which PHP version (7.4, 8.1, 8.2, etc.) a domain runs on and which extensions are enabled. MultiPHP INI Editor adjusts specific settings within a version, like memory_limit or upload_max_filesize, once the version itself is chosen.
My plugin says it needs an extension that isn't available after I switched PHP versions — what now?
Open MultiPHP Manager, click the wrench/gear icon next to the relevant PHP version, and check whether the extension is listed and enabled. Some older extensions don't have builds for newer PHP versions, in which case you'll need an alternative plugin or to hold off on that particular version.
