Continuing the discussion from
Very few if any hosts are gonna cut 5.x servers. There can be huge costs associated with migrating from 5.x to 7. Think about how long it took to erredicate 4.x.
Conversely there are huge savings associated with running version 7
They do that by refusing to run unsupported versions of languages that have potential security holes. So once support for PHP 5.6 ends then the hosting company would be irresponsible if they allowed people to continue using it on their servers if it became known that it contained a serious never to be patched security hole. The hosting company would be meeting their security obligations in that case by requiring that all the sites they host be upgraded to PHP 7 at that point. Any that break as a result are then the owner’s responsibility for disregarding the notification back in 2012 as to the changes that were required.
1 Like
I have seen suggestions that PHP 7 only required half the resources of PHP 5.6 allowing shared hosting providers to fit twice as many accounts on the same number of servers - that’s a huge cost saving for the hosting providers even if they only put 50% more accounts on the same server and let the sites get the benefit of the rest.
1 Like
I’m referring to years worth of development efforts that might not be compatible with php 7. For small sites it might not be all that hard, but for large web applications it would be quite the task. Especially, for those that run on lower versions of 5.
Well presumably such sites would run on dedicated servers where they can run whatever they like and take responsibility themselves for any security issues that their code caused on their server.
Of course professionals will be monitoring the various changes to PHP and would commence making changes as soon as they are first announced - eg. replacing mysql_ calls in 2012 when it was first announced that support for that antiquated interface would end.
In my experience that has been a fairy tale similar to automated testing. People rarely see value in these types of large, none visual tasks,
Not all companies can afford the huge cost that can be associated with the support costs in such cases. Just consider how much Microsoft is making from custom support for IE8 with Government departments and big companies that neglected to upgrade their intranet to work with more modern browsers. All that money just so their browsers will get security patches.
Big companies can keep running old versions of PHP on their dedicated servers until someone finds a way to exploit the security holes. Hosting providers are unlikely to continue offering old unsupported versions if the slightest hint of never to be patched security holes arise.
Anyway with the interface between PHP and mySQL the two improved versions of the interface that are still in use were both introduced in July 2004 so there is no reason why any company that started on the web in the past 12 years would have started using an interface that was obviously going to be eventually removed in the first place.
Anyway any company with a security section should have had that section insisting that one of the new interfaces be used for all new development work from about ten years ago as there are significant security issues with the old interface (wich is one of the many reasons why it was removed).
That’s what gets me. I often see the “too much work” argument.
OK, I get that. But nothing says everything needed to be changed in one go.
But for anything new, or any time old code is worked on, I see no reason to not use the “not so new now” interfaces.
At least that way, when things start falling over there will be less to do - all at once.
1 Like
That’s what kind of happened with Y2K. There were good reasons in the 1950s and 1960s to save on expensive storage by leaving out the century. In the 1970s and 1980s a lot of new code added in the century so that a lot of code didn’t need Y2K fixes. That meant that it only took about 4 years to fix most of the Y2K issues during the 1990s leaving only a manageable number of errors to handle in 2000 itself. The team I worked on encountered three errors in Jan 2000 that had been overlooked - they were all fixed within two weeks so that most clients weren’t even aware of the problem.
1 Like
I can confirm this. I am managing a hosting account (managed VPS without root access) with about 30 web sites and we have the ability to choose any PHP version from 5.2 to 7 for any site. Whenever I change from 5.6 to 7 I can see the CPU load literally cut in half with the same number of page requests.
3 Likes
Most shared hosting providers oversell their infrastructure anyway. But, yes. Being PHP7 performs so much better, they’d still get more out of it.
Scott
A big personal disadvantage is to develop locally using PHP7 and having to remove specific syntax after uploading to a client’s site.
OH how I wished there was a global PHP7 flag available instead of having to remove unique PHP7 statements 
That isn’t a disadvantage it is blatant incompetent. When production web servers are running 5.x you should be running a local box that mirrors that environment as close as possible.
I’m not arguing 7 should be used over 5.x. I’m arguing over the development cost and investment of migrating a STABLE project to a completely new version of php. Especially if that project is using a framework, cms, and/or proprietary code for large, feature rich code base. Comparing the costs/investment of migrating a small website is nothing compared to an older web application.
The reason I develop using PHP7 is because it is far more strict than PHP 5.x and highlights subtle errors and warnings. Also decreases the occurrences of possible future errors.
Removing the new PHP7 features is necessary before the scripts will run without any errors or warnings on PHP 5.x.
As an example for many years I was oblivious to the following incorrect syntax:
ini_set('display_errors', 1);
Changing to the recommended parameters is one less task for PHP 5.x to perform and therefore will make the old scripts slightly faster.
I would prefer having a global declare(strict_types=1); (similar to other language compilers) rather than only having the declaration file wide.
2 Likes
I thought that too, however there are good reasons to leave it at file level.
- To allow strictly typed libraries to work alongside non-strict ones. Surely you aren’t using your own code everywhere, are you?
- To allow type casting at some points in the application. Sometimes it is useful, right?
Any other reasons?
Scott
So you think it is ok to develop on a completely different version of the php than what is on the production server. That blows my mind and I would be looking for the first mistake you make to toss you under the bus. The second you push something to the production environment that breaks it I would take that as an opportunity to highlight the incompetence. That would be magnified if it was something that I had to fix. Its not ok to be doing that and sooner or later its going to bite you.
Now I understand about the file level restriction although would still have preferred an additional super-global level.
Fortunately and seldom, if ever I use “other libraries” and rely solely on the PHP Framework.
Casting is a useful Kludge and maybe avoided by testing the type.
Have you tried testing PHP 5.x scripts with PHP 7?
The additional errors and warnings are very helpful and may actually highlight reasons for having to debug/update the old PHP 5.x scripts.
It is always up to the developer which changes to implement 
Until you break the prod server.