PHP 7.0 still gets security fixes for another year, so nothing breaks today. Test a copy of the site on PHP 7.1 and 7.2, fix what fails, then switch the live site in a quiet week.

Two dates in four days

Most small business sites, WordPress ones included, are built in PHP, a programming language that runs on the host's server.

On Thursday, PHP 7.2 was released. On Sunday, PHP 7.0 left active support: from now on it receives security fixes only, until December 3 next year, and no ordinary bug fixes at all.

Nothing on your site changed over the weekend. What changed is the clock on a version many sites adopted only recently.

The question now is which version to move to, and when.

Where your site might be

The fourth is where most sites should aim this winter. It has been out long enough for plugin and theme authors to fix their problems with it, and its full support runs well into next year.

Which line applies to your site is a one-minute question for your host or web company.

What 7.2 changes

Most of 7.2 is invisible to a business: small speed gains, a modern encryption library built in, and stronger ways of storing passwords that plugins will adopt over time.

Three changes matter to older sites. First, the mcrypt encryption extension is no longer included, so any code still relying on it simply stops working.

Second, functions such as each() and create_function() are now deprecated: they still run, but every use produces a warning, and a later version will remove them.

Third, code that tries to count something that cannot be counted, a quiet habit of older plugins, now triggers a warning each time it runs.

Why not 7.2 today

Every new release is followed by bug-fix releases, roughly monthly, as problems surface on real sites. In the first weeks, somebody's live site is where they surface.

Plugin and theme authors are only starting to test against 7.2, and not every host offers it. A site that moves this week becomes part of the testing.

Waiting a few weeks costs nothing, since 7.1 is fully supported in the meantime.

Why not stay on 7.0

It works, and it will keep receiving security fixes for a year. But ordinary bugs found from now on stay unfixed, and next December even the security fixes stop.

Plugin authors test against the versions most of their users run, and gradually drop old ones. The longer a site waits, the more there is to fix at once.

A move this winter can be planned. A move forced by a host next autumn usually cannot.

Test two versions at once

The routine is the same as for a move from 5.6: a private staging copy of the site, switched to the new version while the live site carries on.

This time, run the copy on 7.1 and then on 7.2. Open each kind of page, submit each form, try a purchase or a booking, and read the error log after each version.

If both pass, 7.1 now and 7.2 after its first fixes is a comfortable plan. If 7.2 fails, the copy has shown what to fix before it matters.

On the live site, errors belong in the log, never on the page. A warning printed above the header tells visitors more about your setup than they need to know.

A worked example

An artificial turf installer with two crews does backyards, dog runs and putting greens. Its WordPress site has a quote calculator: enter the area, choose a grade of turf, see a price range.

The calculator was written for the site four years ago by a developer who has since left the area. The site moved to PHP 7.0 last year, and the owner asked last week whether to switch again.

On Friday the web company ran a staging copy on 7.1 and on 7.2. On 7.2 the calculator returned a blank result, because the code that saved each estimate as a link customers could return to relied on mcrypt.

On 7.1 everything worked, apart from warnings from an old gallery plugin that was due for replacement anyway.

The live site moves to 7.1 this week. The calculator gets rewritten in January, the quiet month for turf work, and the site will be tested on 7.2 again after that.

Customers will notice nothing, which is the point.

The warnings are a free list

Deprecation warnings are easy to ignore, because nothing visibly breaks. They are better read as notice: each one names code that a future version of PHP will refuse to run.

Note which plugin or file each warning comes from and pass the list to whoever maintains that code. A maintained plugin will usually fix them in an ordinary update.

Code written specially for the site has nobody watching it, so its warnings are the ones to budget for.

Questions for your host

Ask which versions it offers, when it plans to add 7.2, whether you can choose the version per site, and whether it ever moves accounts to a newer version itself.

Some hosts switch customers on their own schedule, with a notice that can easily land in a spam folder. Knowing the plan means the switch happens after your test, not before it.

The counter-case

A site still on 5.6 or older faces a bigger move than this week's news, and should go straight to 7.1 with a full test rather than stopping at 7.0.

A simple site on 7.0, with current plugins and nothing custom, can reasonably wait a few weeks for the first 7.2 bug-fix releases, then move once after a short test.

A site due to be rebuilt in the spring can stay on 7.0 until then, provided the rebuild has a real date. For the rest, the advice holds: a tested move to a supported version this winter.

This month

  1. Ask which PHP version is running.
  2. Make a staging copy for testing.
  3. Switch the copy to 7.1, then 7.2.
  4. Test every form and checkout on it.
  5. Read the error log after each test.
  6. Fix or replace whatever fails.
  7. Switch the live site in a quiet week.

Step five is where the decision gets made. The log shows what fails on 7.2 today and what later versions will refuse, none of which a quick look at the pages reveals.

The last deadline of this kind, and why PHP 7 was worth planning for, is covered in PHP 5.6 moves to security fixes only.

Frequently asked questions

What changed for PHP in the past week?

PHP 7.2 was released on Thursday, and on Sunday PHP 7.0 left active support. It now receives security fixes only, until December 3 next year.

Is my site at risk on PHP 7.0?

Not immediately. Security fixes continue for a year, so nothing breaks today, but ordinary bugs stay unfixed and plugin authors will gradually stop testing against it.

Should I move straight to PHP 7.2?

Not untested. It is days old, plugins are still catching up, and some older code fails on it. PHP 7.1 is the safer target for most sites this winter.

What does PHP 7.2 change for older sites?

It removes the mcrypt extension, so code relying on it stops, and it warns about deprecated functions such as each() and about counting things that cannot be counted.

What are deprecation warnings?

Warnings about functions that still work but will be removed in a later PHP version. Each one names code that needs updating, so pass them to whoever maintains it.

Who should handle the PHP upgrade?

Whoever maintains the site. Changing the setting takes one click; the copy, the testing and the error log are the real work, and routine for a web developer.

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.

Site still running PHP 7.0 or older?

Ask us to test a copy on 7.1 and 7.2. We will list what breaks before anything changes on the live site.

Start a Conversation