PHP 5.4 gets no more security fixes after this week's final release. Check the version your site uses, try a copy on PHP 5.6, fix what breaks in old plugins and code, then switch.

The last release came yesterday

WordPress, Joomla and Drupal are all written in PHP, the programming language behind a great many hand-built sites too. Yesterday, version 5.4 had its final release.

From now on nobody fixes it. When a security flaw is found in PHP 5.4, there will be no update to close it.

Plenty of shared hosting accounts still run 5.4, and some still run 5.3, which lost support a year ago.

Your site will look exactly the same tomorrow. The difference is that every month it stays on 5.4 adds to the list of known flaws it will never be protected from.

Where the versions stand

The fourth is the sensible destination for most sites. Moving to 5.5 means moving again sooner, and PHP 7 will be brand new, with many plugins and themes still catching up.

What out of support means

A supported version gets regular updates, and the ones that matter most fix security flaws: ways to make a site run code it should not, or reveal files it should keep private.

Flaws keep turning up in old versions long after support ends. When one is fixed in 5.5 or 5.6, the fix is published, and anyone can work out how to use it against 5.4.

Some hosts run a version of 5.4 maintained by their operating system's vendor, which keeps receiving security patches. Ask yours directly whether that applies, and get the answer in writing.

Finding your version

The hosting control panel usually says which PHP version is in use, and often lets you change it. If yours does not, one email to the host will answer it.

A developer can also upload a one-line test file that reports the version and settings, then delete it straight away, since it reveals more than visitors should see.

Check every site in the account, not just the main one. An old copy of the site or a forgotten blog in a subfolder may be running on something older still.

Why plugins and themes decide the effort

Switching the version is often one setting. The work lies in the code that has to run on the new one.

WordPress itself runs happily on PHP 5.6, as do current versions of Joomla and Drupal 7. The trouble comes from plugins and themes not updated in years, and from custom code written for an older PHP.

The most common problem on older custom sites is the original way of talking to the database. Those functions print deprecated warnings from PHP 5.5 onwards, and PHP 7 drops them entirely.

A plugin last updated three years ago is the likeliest to fail, and the easiest to replace before the move rather than after.

What usually goes wrong

The signs are familiar to anyone who has moved an old site. Warnings appear across the top of pages. A page goes completely blank. A form submits and nothing arrives.

Some failures hide. A checkout that works until the payment step, or an admin screen that refuses to save, only shows up when someone tries it.

Which is why the move is tested on a copy, form by form, before the live site changes.

A worked example

A radon testing company in an Interior city sells long-term test kits through its website, books testing in homes and workplaces, and lets customers look up their results by kit number.

The site runs on WordPress, with a theme bought in 2011 and fourteen plugins, and the host still had the account on PHP 5.4.

When the owner asked his developer to move it, she listed every plugin with its last update before touching anything.

Eleven were current. Two had not changed since 2012, and the results lookup had been written for the site by a developer long gone.

On a test copy running 5.6, WordPress and the current plugins worked at once.

An abandoned slider on the home page printed warnings above the header. The results lookup, built on PHP's old database functions, printed warnings where the results should be.

The slider was replaced with a maintained one in an hour. The lookup took two days: its database code was rewritten with current functions and tried against real kit numbers on the copy.

The other abandoned plugin, a sharing tool nobody used, was deleted. Then the live site moved to 5.6, with the old setting noted in case anything needed switching back.

Test on a copy first

A test copy, at an address only you and the developer know, lets everything run on the new version without customers seeing the failures.

Click through every form, booking, checkout and login, and use the admin as the person who updates the site would. Ask the host for the error log afterwards, which records problems that pages do not show.

Then move the live site during a quiet hour, keeping the old setting ready to restore for the first day.

When the host is behind

Most hosts now offer 5.6. A host that cannot, or will not give a date, is showing you how much attention its servers get.

That is worth a conversation now, before a security problem forces one. Moving to hosting that keeps its software current is a larger job than a version switch, but it is a job done once.

The counter-case

A site made only of plain HTML pages runs no PHP and has nothing to do. A host running a vendor-patched 5.4, and saying so in writing, buys you time rather than an exemption.

And waiting for PHP 7 is not a reason to stay put. It is due later this year, but plugins and themes will need months to catch up, and 5.6 is supported now.

For every other site, find the version, test a copy on 5.6, fix what breaks, and switch.

Before the month is out

  1. Find out which version your site runs.
  2. List every plugin and theme with its last update.
  3. Replace anything abandoned before the switch.
  4. Make a test copy running PHP 5.6.
  5. Test every form, booking and checkout.
  6. Fix warnings in the code rather than hiding them.
  7. Switch the live site with a way back.

Step four is what makes the rest safe. Every problem found on the copy is one your customers never see, and the live switch becomes a formality.

What those warnings mean, and why hiding them is not a fix, is covered in the deprecated warning across the top of the page.

Frequently asked questions

What happened to PHP 5.4 this week?

It had its final release on Thursday. Security flaws found in PHP 5.4 from now on will not be fixed, so sites running it stay exposed to them.

How do I find my PHP version?

Look in your hosting control panel, which usually shows it, or ask the host by email. A developer can also check with a test file deleted afterwards.

Which version should I move to?

PHP 5.6, the newest version and fully supported. PHP 5.5 already gets security fixes only, and PHP 7 is expected later this year with plugins needing time to catch up.

Will my site break on a newer PHP?

Current WordPress, Joomla and Drupal run on PHP 5.6. Problems come from plugins and themes not updated in years and from older custom code, which is why a test copy matters.

Why do plugins and themes matter so much?

Because the switch itself is a setting. Abandoned plugins and themes are the likeliest to use old functions that print warnings or fail outright on newer versions.

Can I just hide the warnings?

Hiding them looks like a fix but leaves the old code in place, and the functions behind the commonest warnings disappear entirely in PHP 7. Replace the code instead.

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 on PHP 5.4?

Tell us the site's address. We will check its PHP version, try a copy on 5.6 and list what needs fixing.

Start a Conversation