Converting custom website from PHP 5.6 to 7.2

[dc2000]

Hi everyone:

I have a custom website that was written using PHP 5. It is currently hosted on DreamHost under PHP v.5.6.

Since about last month they started pushing me to convert to PHP 7.X. So today they sent me an email that they will automatically convert it to PHP 7.2 on Nov. 18.

Thus my question. How different are those versions?

I wasn't using any fancy classes or anything like that. There's probably only a library for integration with PayPal and one for SendinBlue. But they are not mine.

PS. Also do you know if there's a way to test it such conversion from 5.6 to v.7.2. I don't want to perform all work on a live website.

[requinix]

They're quite a bit different, but not as drastically different as some past versions were.

This is a great time to set up a local environment for yourself to develop and test with. It would make doing this upgrade much easier for you.

[dc2000]

3 hours ago, requinix said:

They're quite a bit different, but not as drastically different as some past versions were.

This is a great time to set up a local environment for yourself to develop and test with. It would make doing this upgrade much easier for you.

Thanks. That's what I was afraid of. They'll switch my website and then I'll have to fight with a non-working live version trying to fix it.

Any idea how to set up a test environment? The problem is that I'm on Windows and the web hosting company uses Linux (or FreeBSD) if I'm not mistaken.

[maxxd]

If you've got some time, you could use Docker or install WSL. Otherwise, you'll have to set up another version of your production server and blow things up there instead of the live site.

Edited November 12, 2019 by maxxd

[dc2000]

Man, that's a lot of work. Why are they phasing out php 5.6? I don't use any third party plugins there to be subjected to any old bugs in them.

[Psycho]

1 hour ago, dc2000 said:

Man, that's a lot of work. Why are they phasing out php 5.6? I don't use any third party plugins there to be subjected to any old bugs in them.

From Wikipedia

Official security support for PHP 5.6 ended on 31 December 2018

[cyberRobot]

In case you're not aware, the PHP manual provides a description of the changes here:
https://www.php.net/manual/en/migration70.php

Of course, they don't directly describe the changes from 5.6 to 7.2. You would need to go from 5.6 to 7.0, both of which will no longer be supported by DreamHost in the near future. Then you can go from 7.0 to 7.1, etc.

However, it's probably much easier to set up a test environment like the others have suggested. For the test environment, you could consider setting up a sub-domain through DreamHost. Then upload the web files there to see how they function. More information about sub-domains can be found here:
https://help.dreamhost.com/hc/en-us/articles/215457827-How-do-I-add-a-subdomain-

Also, to delay running into this issue again, you may want to consider moving to 7.3, which is the latest version of PHP that DreamHost supports. According to the following page, that version will receive security updates until the end of 2021.
https://www.php.net/supported-versions.php

Then, if DreamHost follows the same pattern, 7.3 would likely be removed from their servers in late 2022.

[dalecosp]

+1 for a development environment.

I use Oracle's Virtualbox and install a BSD-family OS with Apache+PHP ... you might be able to even find a Docker container or something like that for free out there someplace.

As far as what will happen, the biggest recent changes to PHP, in terms of effect, at our company were removing the old mysql_* stuff (although most of it was long gone, we found out that some infrequently-used LAN software and reports still had some mysql_* stuff in them, and the removal of mcrypt().

Edited November 12, 2019 by dalecosp

[maxxd]

I could be completely wrong, but I think the official Docker PHP image is built on Ubuntu with Apache2x. So it theoretically should be almost as simple as `docker-up`

And @dalecosp, You're kinda killing me with that - I miss Virtualbox and Vagrant by now. Docker is great, but really fiddly and docker-compose files don't make as much sense to me as Vagrantfiles did...

[dc2000]

@dalecosp oh, crap. Most of my MySql queries are done with mysql_* calls, similar to this simplified version:

$link = @mysql_connect($host, $user, $pass);
@mysql_select_db($DBNAME);
$result = @mysql_query($query, $link);

So the entire site will not work.

So what am I supposed to use instead?

@cyberRobot As for your other guys' suggestions, sure, I can probably do all that. The question is why? Why do I need to do all this on a perfectly working website, like if I had nothing else going on in my life!?

Just makes me so mad.

[mac_gyver]

On 11/11/2019 at 6:50 PM, dc2000 said:

Any idea how to set up a test environment? The problem is that I'm on Windows and the web hosting company uses Linux (or FreeBSD) if I'm not mistaken.

if your code is not making any shell/system/passthru calls, it doesn't matter what operating system you use for a development system. all that matters is you have the same set of extensions and php.ini settings between the development system and the live server. you can use one of the all-in-one development packages.

15 minutes ago, dc2000 said:

oh, crap. Most of my MySql queries are done with mysql_* calls, similar to this simplified version:

the mysql extension became deprecated as of PHP 5.5 (released in 2013) and would have been throwing errors in your code if not for the @ error suppressors. don't ever use @ error suppressors in any code. on a live/public server, your php error related settings should be set to log all errors.

30 minutes ago, dc2000 said:

So what am I supposed to use instead?

if you are faced with updating old code that uses the mysql extension, do yourself a favor and 1) jump directly to use the very simple and future-proof PDO extension, 2) use prepared queries when supplying external/unknown data to an sql query statement (this actually simplifies the sql query syntax), 3) using implicate binding (supply an array of values to the execute call) for prepared queries, and 4) use exceptions for errors and in most cases let php catch and handle the exception where it will use its error related settings to control what happens with the actual error information (database errors will 'automatically' get displayed/logged the same as php errors.) doing these four things greatly simplifies the implantation of your database specific code, which will let you eliminate, rather than convert code, shortening the task.

[mac_gyver]

how much total code/files is/are there? if you post your code (less any database/api credentials) somewhere (in the forum or on github) you would get more specific help about what you do need to change. since your code works under php5.6, you don't have to deal with register_globals, and the only things to update would be those that have been removed, are backward incompatible, or are deprecated (to future-proof) in going from 5.6 to 7.x.