PHP 7.3 Arrives and PHP 5.6 Has Three Weeks Left

Two pieces of news in one week

PHP 7.3 was released yesterday: a new version of the language WordPress is written in, along with most of the systems behind small business sites.

In the same month, PHP 5.6 reaches the end of its security support. After December 31, the PHP project fixes no newly discovered flaws in it. PHP 7.0's security support is ending at the same time.

The two items point in different directions. The new release is optional and can wait. The deadline cannot.

Where sites stand this week

• On 5.6: security fixes end in three weeks.
• On 7.0: the same, ten days later.
• On 7.1: supported until December next year.
• On 7.2: supported for about two more years, the sensible target now.
• On 7.3: a day old, with plugins and hosts still catching up.

The second is the one people miss. A site moved to 7.0 a year or two ago feels current, and it falls out of support only ten days after 5.6.

What the date means

Nothing switches off on January 1. A site on 5.6 keeps loading exactly as it did on December 31.

What changes is that each new flaw found in 5.6 stays open. Plugin authors stop testing against it, hosts start treating it as a liability, and the risk grows quietly month by month.

That is why the date matters less as a cliff than as a reason to stop postponing.

Why not go straight to 7.3

A major release is followed within weeks by point releases, fixing problems that only appear once thousands of sites run it. Early adopters find those problems on their own sites.

7.3 also tightens a few rules. Some older plugins print warnings on it or fail outright until their authors catch up, and some hosts do not offer it yet.

There is a quieter reason too. Moving from 5.6 already crosses the large break of PHP 7. Adding 7.3's changes on top means that when something fails, nobody can tell which change caused it.

WordPress itself is ready for 7.3 as of version 5.0. Most sites are more than WordPress, though.

Three weeks with Christmas in them

The calendar is less generous than it looks. Two of the three weeks are the busiest of the year for stores, and the people who test upgrades are busy too.

For a shop, changing the software under the checkout in the week before Christmas is a poor idea. Either do it next week, or book it for the first full week of January.

A booked date in early January is a reasonable plan. An open-ended intention to get to it is not, because that is how sites are still on 5.6 next summer.

Custom code is where 5.6 hides

WordPress, current themes and maintained plugins mostly made the move to PHP 7 long ago. The risk lies in code written for one site and never revisited.

A price calculator, a customer login, an import from the accounting system, a booking script: each was written by somebody, often a developer long gone, for the PHP of the day.

Nobody updates that code automatically, and nobody else is testing it. List every piece of it before choosing a date.

A worked example

A pallet manufacturer with a yard and two production lines sells new and recycled pallets to warehouses, growers and distributors.

Its site, built in 2012, includes a quote calculator for custom sizes and a login where regular customers reorder. Both were written for the company by a developer who has since retired.

In October the host emailed to say accounts still on 5.6 would be moved to a newer version in January. The company's web firm tested a copy of the site on 7.2.

WordPress, the theme and the plugins were fine once updated. The reorder login failed: it relied on an encryption add-on that PHP warned about in 7.1 and removed from 7.2.

Had the host moved the account as planned, regular customers would have met a broken login on the first working day of January.

The login was rewritten to use what PHP now includes, tested on the copy, and the live site moved to 7.2 this week.

What to ask your host

Hosts are handling the date differently. Some will move remaining accounts to a newer version in the new year, some will leave them alone, and a few patch old versions on their own servers.

Ask which applies to your account, and when. Ask which versions are offered, whether each site can be set separately, and how quickly a change can be reversed.

Make sure the answer reaches somebody who will act on it, not an inbox set up by whoever opened the account.

When 7.3 makes sense

7.3 brings some speed improvements and new features for developers, but nothing like the jump from 5.6 to 7. A site that runs well on 7.2 gives up very little by waiting.

Revisit it in the spring, once the first point releases are out and your plugins say they support it. Test it on a copy in the same way, and move when the copy is clean.

The counter-case

Sites already on 7.1 or 7.2 have no deadline this month, and can leave both pieces of news until spring.

A site on a host that patches 5.6 itself is safer for a while, though plugin authors will still drop support, so the work is delayed, not cancelled.

And a site being replaced in January can make the move during the rebuild, as long as the rebuild keeps its date.

Everyone else: get off 5.6 first, onto a version tested on a copy, and let 7.3 wait.

Before the end of the month

1. Find the PHP version each site runs.
2. Ask your host about its January plans.
3. Update WordPress, the theme and plugins.
4. List any custom code written for the site.
5. Test a copy running PHP 7.2.
6. Switch next week or book early January.
7. Leave 7.3 until the spring.

Step four is the one that finds the real risk. Maintained software has had years to get ready; code written once for your site has had nobody looking after it.

The upgrade itself, done in the right order, is covered in the PHP 7 upgrade your host keeps offering.

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.