The PHP 7 Upgrade Your Host Keeps Offering

The notice in the control panel

Many hosting control panels now show a notice suggesting a newer version of PHP, and some hosts have started emailing customers about it.

PHP is the programming language that WordPress, and most other systems behind small business sites, use to assemble each page. Your host runs it; every page depends on it.

A great many small business sites still run PHP 5.6. It works, and nothing on the site looks wrong. But it receives security fixes only until December 31 this year, and none after.

So the upgrade is coming either way. The question is whether it happens on a planned evening or in a hurry.

Why so many sites are still on 5.6

PHP 7 came out at the end of 2015. Two years on, plenty of sites have not moved, for understandable reasons.

• Hosts rarely switch accounts themselves, because a switch can break a site.
• WordPress still runs on far older versions, so the dashboard never complains.
• Warning emails go to whoever opened the account, often years ago.
• Old plugins make the switch genuinely risky.
• Nobody owns the question, so it waits.

The fourth is the real obstacle. WordPress itself made the move cleanly. The risk sits in add-ons whose authors stopped maintaining them before PHP 7 existed.

What PHP 7 offers

Speed, mainly. PHP 7 is roughly twice as fast as 5.6 at the work WordPress does, and it uses less memory doing it.

That shortens the part of loading a page that happens on the server, before anything is sent. It shows most on pages that cannot be cached, such as a shop's cart, and in the dashboard.

Large photographs and heavy scripts are a separate problem, and PHP 7 does nothing for them. What it changes is the wait before the server starts sending anything at all.

And the newer versions keep receiving security fixes: 7.1 until December next year, 7.2 for longer still.

What breaks

PHP 7 removed some old features entirely. The most common casualty is the original set of functions older code used to talk to the database. They are simply gone.

Code that still relies on them stops with a fatal error the moment it runs. Depending on where that code sits, the result is a blank page, an error message, or something much quieter.

The quiet cases are the dangerous ones. A plugin that only runs when a form is sent or an order is placed can fail while every page still looks perfect.

What the upgrade involves

Done properly, it is a short project in a fixed order.

Bring WordPress, the theme and every plugin up to date first. Current versions of maintained plugins nearly all work on PHP 7. Anything not updated in years needs replacing, because nobody is going to fix it.

Then build a staging copy of the site on the new version and test what the site does, not just how it looks: send every form, place a test order, log in, edit a page.

Then the live site moves on a quiet evening, and the server's error log is read each morning for a week.

A way back

Every upgrade needs a route back that is known before it is needed.

That means a full backup of files and database taken just before the switch, and knowing exactly how to return the site to 5.6 if something fails. On most hosts that is the same setting, changed back.

Make no other changes that evening. If the PHP version is the only thing that changed, switching it back undoes the problem cleanly. If three things changed, nobody knows which to undo.

A worked example

A water treatment dealer had a website whose busiest page was a service request form: salt deliveries, filter changes and repair visits.

An office assistant saw the PHP notice in the control panel, chose the newest version, and checked the home page. It looked fine, so the change stayed.

The form's plugin, last updated in 2013, used the old database functions PHP 7 removed. The form page loaded normally, but pressing send produced an error, and no request reached the office.

It took four days and a run of irritated phone calls to connect the two. Customers had assumed their requests were received.

Switching back to 5.6 restored the form within minutes. The proper fix followed over the next week: a maintained form plugin, tested on a staging copy running PHP 7, then the live switch on a Sunday evening.

Which version to choose

PHP 7.2, released at the end of November, is the newest. Some plugins have not yet confirmed they work with it, and it flags a few things older code relies on, which can fill the error log with warnings.

PHP 7.1 is the cautious choice for a site with many older plugins. PHP 7.0 is not worth choosing now: its security support ends at about the same time as 5.6's.

Whoever maintains the site should test on the version they intend to use, and say which one and why.

Who should do it

The setting is one click. The work around it is not.

Checking plugins, building a staging copy, testing every form and transaction, and reading an error log are routine for someone who maintains WordPress sites regularly, and unfamiliar to almost everyone else.

The click is only risky when nobody has done the rest. So the notice in the control panel is worth forwarding to that person rather than answering yourself.

The counter-case

Not every site faces the same amount of work.

A site built entirely from plain HTML files does not use PHP, and the notice does not apply. A site built in the last year or two, with current plugins, may need little more than a test and a switch.

A site due for a rebuild this spring can reasonably move to PHP 7 as part of the rebuild rather than twice. That only holds if the rebuild has a date and keeps it, since December 31 will not move.

Everyone else should schedule the upgrade now, while there is most of a year to do it calmly.

The order to do it in

1. Find out which PHP version runs now.
2. Update WordPress, the theme and every plugin.
3. Replace plugins their authors have abandoned.
4. Test everything on a staging copy running PHP 7.
5. Take a full backup before switching.
6. Switch the live site on a quiet evening.
7. Send every form again next morning.

Step four is where the risk is removed rather than moved. A form that fails on a staging copy costs nothing; the same failure on the live site costs every enquiry until somebody notices.

Testing changes on a copy instead of the live site follows the same logic as WordPress 4.9 and the code editor warning.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.