Switching version is one click, and it is written out step by step in «How to change your PHP version». This article is the other half, the half that is actual work: working out which version your site needs, what breaks when you go up, how to test first, and how to go back.
Working out which version the site needs
| 1 |
Start with the application. WordPress, PrestaShop, Laravel and the rest all publish their supported versions on a requirements page. That is the floor, not the answer.
|
|
| 2 |
Then the plugins and the theme. This is where it is actually decided. Your site does not run on the version the application supports: it runs on the version everything supports. One plugin abandoned years ago rules the whole site.
|
|
| 3 |
Custom code publishes no requirements at all. If the site was written for you, ask whoever wrote it. If that person is long gone, treat the site as if it were on the floor version and test with double the care.
|
|
| 4 |
Check which version you are on right now. cPanel tells you, and WordPress itself shows the PHP version on its site health screen. Without that starting point you do not know whether you are going up one step or five.
|
|
|
Jumping five versions at once is how you lose an afternoon. If the site is far behind, go up one version at a time and test in between. It takes longer, but when something breaks you know exactly which two versions it happened between, and that saves hours of guesswork.
|
What breaks, and why
Every new PHP version removes things the previous one had. It is not a whim: these are old functions that were flagged for removal years earlier. The trouble is how much code still uses them.
| What happens |
How you recognise it |
| Removed function |
Blank page or critical error on the very first load, with something like call to undefined function in the error log. The easiest case of all: loud and immediate. |
| Warning promoted to error |
Code that used to grumble and carry on now stops. Typical of old themes. Also visibly broken. |
| Missing extension |
The site opens but one specific feature stops working: images are not resized, the payment gateway cannot talk out, accented characters come out wrong. Each version has its extensions enabled separately, so when you switch you inherit the new version's, not the old one's. |
| Silent change |
By far the worst. The site opens, everything looks fine, and some comparison, rounding or sort order quietly starts returning something else. Nobody notices until somebody spots a wrong total. |
Because of that last row, «I opened the home page and it looks fine» is not a test. The home page is usually the part of the site that runs the least code.
Testing properly, first
| 1 |
Copy the site to a subdomain. This is the step everybody skips and the only one that makes the rest safe. A test subdomain costs nothing and nobody sees it.
|
|
| 2 |
Change the version on the copy only. The PHP version is chosen per domain, so you can have the live site on one version and the test copy on another, at the same time, on the same plan.
|
|
| 3 |
Walk through the things that make money. Not the pretty pages: the contact form all the way to receiving the e-mail, customer login, search, the cart through to the last step of payment, the admin area, and one automated e-mail going out.
|
|
| 4 |
Read the error log after the test, not just the screen. Plenty of things fail without the visitor ever seeing it. Errors lives under the Metrics section of cPanel.
|
|
| 5 |
Only then change the real site. And at a quiet hour: the change is instant, but you want to be at the keyboard if it is not.
|
|
|
If you cannot duplicate the site, do at least two things: take a backup the same day, and make the change at your quietest hour. It is not equivalent, but it turns a possible problem into a short one.
|
Going back
This is the reassuring part, and the reason it is always worth trying: the version change is reversible and it is instant.
| 1 |
On the same screen where you moved up, pick the previous version. The site is back within seconds.
|
|
| 2 |
You do not need to get into the site to do this. Even if the site is throwing a critical error and the admin area will not open, the PHP version is changed in cPanel, which is a separate panel. You are not locked out.
|
|
| 3 |
Clear the cache afterwards, both the site's and the browser's. A cached error page keeps appearing after the problem is fixed, and we have watched plenty of people conclude the rollback failed when it had not.
|
|
| 4 |
Then, and only then, go to the error log and find the culprit. With the site up you have time; with the site down you do not.
|
|
|
Rolling back is a tactical retreat, not a solution. A PHP version out of support stops receiving security fixes, and the code stays there with holes everyone knows about. If one plugin is keeping you on an old version, the plugin is now the problem: replace it, update it, or pay someone to adapt it. Do not just leave it there indefinitely.
|
|
One pleasant side effect: newer PHP versions run the same code faster. A good number of «the site is slow» complaints are solved right here, without touching anything else. For everything else that weighs on a site, see «The site is slow: what actually makes a difference».
|
|
Not sure which version your site needs, or moved up and broke something? Send us the error message.
Open a support ticket
|
RECOMMENDED PRODUCT Web hosting with cPanel Domain and SSL included, daily backups and the panel you already know. from $10.00/mo See plans |
Português
English
