5 ms·

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 s

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.
  - lolc 7y ago
    Those smaller companies will find out maintenance is costly either way.
    - dehrmann 7y ago
      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?
      - reallydude 7y ago
        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-improvements/ https://feryn.eu/blog/php-7-is-now-available-new-features-im...)
  - trilila 7y ago
    Agreed with both statements, but things need to move forward.
nness 7y ago
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.

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.
- lolc 7y ago
  Those smaller companies will find out maintenance is costly either way.
  - dehrmann 7y ago
    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?
    - reallydude 7y ago
      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-improvements/ https://feryn.eu/blog/php-7-is-now-available-new-features-im...)
- trilila 7y ago
  Agreed with both statements, but things need to move forward.

nness 7y ago

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.