Hacker News Reader

Comment by TazeTSchnitzel | Hacker News Reader

PHP 7's changes shouldn't affect most 5.6 code, and the code that is affected should not be difficult to fix. It's not supposed to be a Python 2/3 situation.

View on HN

In theory, yes. However as the Germans say "the devil is in the details". The .patch file for magento 1 for PHP7 compatibility is around 1.9 MB (iirc)! In the standard PHP5 project you have literally millions of lines of third party code, that one shold not touch with a stick. Are you really going through all of this code to check if something is maybe going to break at runtime? What if the legacy project has 0 tests?

Another problem are the Docker images. The PHP project still provides Docker Images for 5.6, however to my knowledge they are not updated anymore (perhaps I'm wrong). So what about all the security vulnerabilities in the underlying linux image? (I just verified and the latest php 5.6 image is from January 2019)

What situation are you in where security vulnerabilities in the Docker image are important to fix, but updating from End-of-Life support for the language isn't? (Or even where security of an old Docker image is important, but "has 0 tests" isn't a concern?).

That being said, using a newer underlying Linux image for a Docker image is as copying the Dockerfile and building it, isn't it?

Sure all these problems are important to address. But often there is a lack of time/interest to do it.

I think the PHP project should simply delete the 5.6 image, since it is insecure and EOL'ed. Then if somebody is interested they can provide an alternative image somewhere...

Plainly deleting the image will cause existing setups to break. Something like `cargo yank` would be more appropriate where you can still download the version for existing projects but you cannot use it in new projects anymore. Unfortunately as far as I know docker has no support for anything like that.

Magento 1.x reaches end of life June, 2020 (if they don't extend it... again).

I'd be more concerned about having a Magento 1 site in the wild, than the upgrade path to PHP 7.

Magento is not exactly known for well written code, actually it is full of anti patterns and antiqued practices. PHP 7 was released in 2015, and if authors of those millions of lines of code can't be bothered to upgrade then probably their code should not be used.

> Magento is not exactly known for well written code

As are many/most PHP 5.6 projects

> Probably their code should not be used.

In reality it is - unfortunately. And many smaller companies don't have the capacity to change.

Those smaller companies will find out maintenance is costly either way.

And it's worse than just maintenance cost. Do you think a good PHP dev wants to join a shop that's still on 5?

There was nothing crippling about php5 when it came out, why would it matter now? Not having some nice-to-haves like null coalescing, return types, etc are not core features. The biggest php7 selling point was speed improvements, which isn't even on some lists (https://feryn.eu/blog/php-7-is-now-available-new-features-im...)

Agreed with both statements, but things need to move forward.

Reply on news.ycombinator.com