Nothing breaks today: PHP 5.6 still gets security fixes until the end of next year. Use the time to move to PHP 7 properly, testing a copy of the site and its plugins before switching the live site.

What changed today

PHP is the programming language most small business websites run on, WordPress sites included. Your host runs it on the server, and every page passes through it before reaching a visitor.

Each version of PHP is supported in two stages: first with fixes for ordinary bugs and security problems, then with security fixes only, and after that with nothing at all.

PHP 5.6 entered the second stage today. Security fixes continue until the end of next year. Ordinary bug fixes have stopped.

Nothing on your site is different this morning. What has changed is that a date now exists, and the work it implies is better done early than late.

Where the versions stand

The fourth matters more than today's date. A site on 5.5 or 5.4 is already running without security fixes, and plenty of shared hosting accounts were set up on those versions years ago and never changed.

Finding out which version you have

Most hosting control panels show the PHP version, often under a heading about software or PHP settings. Some let you choose it separately for each domain.

If you cannot find it, ask the host in writing, or ask the developer who maintains the site. The answer takes them a minute.

Do not assume. The version chosen when the account was opened is often the version still running, whatever the host now offers new customers.

Why PHP 7 is worth planning now

Speed is the obvious reason. PHP 7 does the work WordPress asks of it in roughly half the time 5.6 needs, with less memory, which shortens the wait before a page starts to arrive.

Support is the other. PHP 7.1 will keep receiving fixes after 5.6 stops, and once a site runs on PHP 7, later moves between versions are usually far smaller steps than this one.

And hosts will not run old versions forever. When a host retires one, accounts move on the host's date, after a notice that may go to an old email address, with no testing at all.

Moving this year, on your own schedule, avoids that, and avoids the queue of sites that will all need the same work late next year.

What decides how hard it is

WordPress handles PHP 7 without trouble. The difficulty, when there is any, sits in what has been added to it.

Plugins nobody has updated in years are the usual suspects. Their authors stopped work before PHP 7 existed, and some rely on features it removed.

Themes edited directly come next. Changes made inside a theme, rather than in a separate child theme, make updating it risky, so it often has not been updated.

Then there is custom code a developer wrote for the site years ago, such as a booking tweak or an import from a supplier's spreadsheet. Nobody has read it since.

The licence that quietly lapsed

One case catches even careful owners: the premium plugin bought once, years ago.

Paid plugins usually deliver updates only while the licence is current. When it lapses, the plugin keeps working and the update notices simply stop, so the installed copy grows older without anyone noticing.

A version that works with PHP 7 may well exist. The site just has not received it. Renewing the licence is often the whole fix, but someone has to spot it first.

Testing on a copy of the site

The safe way to find all this is a staging copy: a duplicate of the site at a separate address, hidden from search engines and the public, set to run PHP 7 while the live site stays as it is.

Then test what the site does rather than how it looks: submit each form, run a test purchase, make a booking, search, log in, and confirm the emails the site sends still arrive.

Read the server's error log as well. It records warnings and failures that never show on a page.

A worked example

A family mushroom farm sells fresh and dried mushrooms to restaurants and at farmers' markets, and restaurants place their weekly wholesale orders on its WordPress site.

The site was built in 2012 and had run on PHP 5.4 ever since. The host offered newer versions in the control panel, and nobody had changed the setting.

Last autumn the site's developer built a staging copy, set it to PHP 7 and worked through a test list. Every page looked right. Submitting the wholesale order form produced a blank page.

The form ran on a premium add-on bought with the site, whose licence had lapsed after the first year. The installed copy dated from 2012.

That copy reached the database in an old way that PHP 7 no longer supports. The current version did not.

Renewing the licence and updating the add-on fixed the copy. The live site moved the following Sunday evening, after the week's order deadline, and Monday's orders arrived as usual.

The switch itself

Once the copy passes, the live change is short.

Bring the live site's plugins up to date to match the copy, take a full backup, and change the PHP setting at a quiet time, with someone on hand to test.

Repeat the most important tests on the live site straight away, and check the error log over the next few days. Know before you start how to set the version back.

The counter-case

Some sites have little or nothing to do.

A site built from plain HTML pages does not run PHP at all. A site built recently, with maintained plugins, may need only a quick test before the switch.

A site already scheduled for a rebuild this year can make the move as part of it, provided the rebuild really goes ahead.

Everyone else should treat today as the start of a calm, planned upgrade: tested on a copy, then switched.

Before the switch

  1. Find out which PHP version runs today.
  2. List every plugin and its last update.
  3. Renew lapsed licences for paid plugins.
  4. Build a staging copy running PHP 7.
  5. Test every form and order on the copy.
  6. Take a full backup before switching.
  7. Check the error log for a few days.

Step five is where the upgrade succeeds or fails. Pages that look fine prove very little, because the code most likely to break runs only when someone presses send.

The other job worth booking while the developer has a staging copy open is covered in which kind of security certificate a small business needs.

Frequently asked questions

What changed for PHP 5.6 today?

It moved from active support to security fixes only. Ordinary bugs will no longer be fixed, while security problems will be patched until the end of next year.

Will anything break on my site today?

No. Nothing on the site changes today. The date starts a clock: once security fixes end, newly found flaws in PHP 5.6 will stay unfixed.

What if my site runs PHP 5.4 or 5.5?

Then it is already running without security fixes, which matters more than today's date. Those sites belong first in line for a tested move to PHP 7.

Why move to PHP 7 at all?

It handles WordPress in roughly half the time 5.6 needs, uses less memory, and will be supported for longer. Hosts will not keep old versions running forever either.

What usually breaks in the upgrade?

Rarely WordPress itself. Problems hide in abandoned plugins, premium plugins whose licence lapsed so updates stopped, themes edited directly, and custom code written years ago.

Why test on a copy of the site?

Because a failure on a copy costs nothing. Pages can look perfect while a form or checkout fails, and only testing what the site does will find it.

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.

Not sure which PHP version your site runs?

Send us your site's address and your host's name. We will find out and tell you what the move involves.

Start a Conversation