5 ms·

Somebody should fork PHP 5.6. There is a lot of Software still depending on it and it is unrealistic to expect companies to migrate millions of lines of third p

Somebody should fork PHP 5.6. There is a lot of Software still depending on it and it is unrealistic to expect companies to migrate millions of lines of third party code to PHP 7.

unicornfinder 7y ago
Honestly I don't think that's a bad idea. Where I work I develop a web app that's written in Rails, and it's replacing a legacy PHP 5.6 app. Now here's the thing - no-one is using the PHP app anymore, but we do still have some old data on there that we made a decision not to port over to the new app. At the time it seemed like it wouldn't be a problem - just keep an old version of the app up for those who need to view historical information. Now I'm thinking I'll have to set aside some time to either port it to PHP 7 (which isn't really a priority) or come up with something else for viewing that historical data.
- ebiester 7y ago
  Can’t you hide it behind a vpn?
TazeTSchnitzel 7y ago
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.
- naranha 7y ago
  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)
  - rgoulter 7y ago
    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?
    - naranha 7y ago
      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...
      - vbsteven 7y ago
        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.
  - trilila 7y ago
    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.
    - naranha 7y ago
      > 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.
Ayesh 7y ago
I really hope nobody does this. OS vendors backport security vulnerabilities, and that should be it. Like the other commenter said, PHO 5.6 to 7 upgrade isn't that hard. If it is, there's a very good chance they are doing something devastatingly wrong (like using mysql_ extension).
- ebiester 7y ago
  There are companies who do this for Ruby on Rails. If someone can’t upgrade, for whatever reason, they can pay a third party for security updates. It works pretty well.

Somebody should fork PHP 5.6. There is a lot of Software still depending on it and it is unrealistic to expect companies to migrate millions of lines of third party code to PHP 7.

unicornfinder 7y ago

Honestly I don't think that's a bad idea. Where I work I develop a web app that's written in Rails, and it's replacing a legacy PHP 5.6 app. Now here's the thing - no-one is using the PHP app anymore, but we do still have some old data on there that we made a decision not to port over to the new app. At the time it seemed like it wouldn't be a problem - just keep an old version of the app up for those who need to view historical information. Now I'm thinking I'll have to set aside some time to either port it to PHP 7 (which isn't really a priority) or come up with something else for viewing that historical data.

ebiester 7y ago
Can’t you hide it behind a vpn?

TazeTSchnitzel 7y ago

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.

naranha 7y ago
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)
- rgoulter 7y ago
  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?
  - naranha 7y ago
    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...
    - vbsteven 7y ago
      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.
- trilila 7y ago
  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.
  - naranha 7y ago
    > 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.

Ayesh 7y ago

I really hope nobody does this. OS vendors backport security vulnerabilities, and that should be it. Like the other commenter said, PHO 5.6 to 7 upgrade isn't that hard. If it is, there's a very good chance they are doing something devastatingly wrong (like using mysql_ extension).

ebiester 7y ago
There are companies who do this for Ruby on Rails. If someone can’t upgrade, for whatever reason, they can pay a third party for security updates. It works pretty well.