Upgrading from PHP 5.6

Why PHP 5.6 is a big jump

PHP 5.6 came out in 2014. A site moving from it to a currently supported version crosses two major releases, PHP 7 and PHP 8, and each one removed things older code relied on. PHP 7.0 alone removed:

• The old database functions (mysql_ functions) that many older sites use to read and save pages, products and customers. That code has to be rewritten to use the newer methods (mysqli or PDO)
• An older way of searching text (the ereg functions)
• A risky shortcut for search and replace (preg_replace with the /e modifier)
• An old way of reading form data sent to the site ($HTTP_RAW_POST_DATA)

PHP 7 also warned that code written in the PHP 4 style (a setup function with the same name as its class) was on the way out. PHP 8 then stopped running it, so objects quietly miss their setup and things fail further along.

Old plugins, themes and add ons

On a WordPress, Joomla or similar site, most of the code comes from plugins, themes and extensions. If a site has stayed on PHP 5.6 this long, those are usually years out of date too, and so is the core software itself. Some have newer versions that work on modern PHP. Others were abandoned by their authors and will never get a fix, so they need replacing or patching.

We list everything the site uses, check each item, and tell you what can be updated, what needs replacing and what we can fix in place.

Why we often upgrade in stages

Going from PHP 5.6 to a currently supported version in one step means fixing everything at once and not knowing which change caused which problem. On larger or custom sites we usually work in stages on a private copy of your site (a staging copy): first making the code run on PHP 7, then on a currently supported PHP 8 version. Each stage is tested before we move on.

Before we start, we take a full backup of the files and database. Your live site keeps running untouched while we work, and only moves once the copy is working and you have agreed to the switch.

Things that catch people out

• Server settings such as the memory limit, upload size and timezone often reset when a host changes PHP version, so dates can shift and big uploads can fail
• Scheduled tasks (cron jobs) on shared hosting can run on a different PHP version from the website and break separately
• Encoded files (ionCube) need a loader that supports the new PHP version, or they stop working entirely

Is a rebuild the better option?

Sometimes, but less often than people expect. If the site does what your business needs, updating the code underneath is usually less disruptive than starting again. If we find the code is not worth saving, we tell you plainly and explain why.

PHP versions and their support dates

Bug fixes come first; after that a version gets security fixes only, then nothing at all.

Dates from php.net. Your host may offer only some of these versions.